About a repository with samples. USB CDC-ACM does not work correctly for me. Advise, if possible, how to solve the problem.
Closed this issue · 15 comments
Hello!
Thank you for your hard work on Azure RTOS.
If possible, I have a few questions for you:
- Azure RTOS has many components and using them on microcontroller platforms we use not one of them, but several at once. You do not have a code repository with the samples code on some microcontroller. Only Release of this repository. It would be great if you did this. This will greatly help spread the use of Azure-RTOS among developers!
For example, I collected your (and one added) samples of STM32F746-Discovery in one repository - see the link. But this is not an official repository. And I would like your, official repository.
It seems to me that STM32F746-Discovery is an ideal microcontroller platform for Azure-RTOS. It is very common among developers, it has an LCD screen for GUI, Ethernet, USB (FS and HS). - I have problems with my implementation of the example for the USB CDC-ACM Device. The project is located here - see the link. It is NOT fully functional. In the direction of the host STM32F746-Discovery can send data, but data does NOT come back from the host to it. Please, help me solve the problem.
Thank you for your work and good luck!
Hi @AleksBak - we cannot possibly support every dev board out there. As we finalize our partnerships with Microchip, Renesas, ST, and NXP, they will create workspaces for their dev boards.
Do you have a USB analyzer like the Beagle https://www.totalphase.com/products/beagle-usb480/ to see what's actually happening on the bus? We need more info about what is going on. @nisohack Can you help?
Hi @AleksBak, it looks like you're using the STM32Cube IDE project. I have created a simple CDC-ACM demo that echoes data to the host - you can download it here: sample_usbx_device_cdc_acm_echo.zip. In order to use this demo, place it in the 'sample_usbx_device_mass_storage' project and exclude the original storage demo from the project. You also have to make sure the CDC-ACM Device code in the 'ux' STM32Cube project is not excluded (it is by default); the CDC-ACM Device code is in 'usbx_device_classes'.
Let me know if you have any problems.
Hi @nisohack !
Thank you very much for the working project!
Very strange, but it works!
Strange because BEFORE THIS, I already (IMHO) saw some problems in the initialization of the USB HS registers STM32 when creating endpoints. But your code works! See this project. I will still check some things and WRITE LATER to you my thoughts (why I suddenly decided that I found incorrect initialization when creating endpoints). I am very grateful to you!
Hi @goldscott !
Thank you very much for your reply! Excuse me if I answer late.
I do not have the hardware USB analyzer you are talking about. I will ask my company and maybe they will get it for me (now COVID and it is unlikely it will be, but I will hope)
However, as it seems to me, in this case, I can do with a software analyzer (for example, this one - https://desowin.org/usbpcap/), since there are no problems on the host and driver side. And we see that the packets go from the host to the device, to its endpoint with the address 0x02 (EP OUT), and on the device, in response, NO interrupts occur (there is no response in the GINTSTS register, etc.). I found it was wrong initialization when creating endpoints. But this is still preliminary and IMHO. I will report on what I did and what I discovered. nisohack's project is working!
It also seems to me that still having a complete repository with samples of AZURE RTOS for at least some board (for example, I use different boards, but I think that STM32F746-Discovery is the most optimal and very common for this) is a good idea. But it is up to you to decide and I am very grateful for your answers. Especially @nisohack !
Hi @goldscott.
I want to write again - your example now works (works but only with certain endpoint numbers and exactly those that are in the example now!!). Thank.
Earlier you sent me (by mail) an example and it did not work then and I thought that there were problems with creating endpoints. And I began to study the USB HS registers of the controller and how to program them. It is very difficult and while I don't understand much about this.
Anyway, it seems to me that there are some incorrectly working places in the code of the USBX library. For example, after switching to Suspend Mode, the device is deactivated. and after exiting the Suspend Mode, it no longer works.
Besides. I know a developer who found a critical bug in the code of the NetX library! And it is really critical (it would be better if he wrote it to you). So I was asking about a repository with all libraries together. But you write that it is technically impossible now...
Then we will have to wait and see what happens next. Regards. Thank.
Hi @AleksBak - sorry I missed this. Did your developer inform us of the critical NetX bug? Could you please do that. Thanks!
Hello, how are you, @goldscott !
I asked 2 days ago the person I wrote about earlier. I waited for his answer. But he replied that due to being busy, he could not do it now. I'll just briefly write you what the problem is (everything turns out to be very simple as it might seem):
before exiting the function
"UINT _nx_ftp_client_active_transfer_setup (NX_FTP_CLIENT * ftp_client_ptr, ULONG wait_option)" add the following:
/ * Release the packet. * /
nx_packet_release (packet_ptr);
Otherwise, sooner or later, there will be an exhaustion of packets in the network packet pool of the physical media driver Ethernet, RNDIS, WiFi ... (but not in the packet pool of the TCP stack). See also here.
In addition, I myself discovered that you have 100% errors in the USB HS (FS) code and they are associated with an incorrect exit from the SUSPEND device mode (since there is no activation at all), the endpoint addresses and packet sizes are not completely configured correctly (not all variants are here work - and here I’ll probably study the USB HS registers properly before confidently answering here, but there is incorrect work here - 100% and, as it turned out, I have a hardware USB analyzer, but it's only full speed, unfortunately :( ).
If you had one common repository with all the components of Azure RTOS, it would be great. And not as now they are all separately. That is, one could fork from one source.
Could you tell (if you know and have a desire) how to fork on github from many repositories into one repository? This information would be very useful in this case and not only for me - for others too. Then there would be such a solution to the problem at least.
Thank you and good luck.
Hi @AleksBak - sorry for the delay. Thanks for letting us know about this FTP issue - I'll have notified our NetX team to look into this bug. And thanks for the link to the forum!
As for this USB issue, can you show me what file this is happening? or explain what is going on a little more. Is it specific to the STM32 registers? Debugging USB is hard, and we want to make sure both HS and FS work properly!
I'm not a github expert, so I don't know how to fork multiple repos into one. But this sounds like what submodules are for. @PProvost - any ideas here?
Hi @goldscott. Sorry for being late with the answer - I thought I would study USBX a little more and try to fix the errors myself, but it didn't work out for me because it takes a lot of time to study it. And so I decided to answer as soon as possible.
There, in the "ux\usbx_device_controllers\ux_dcd_stm32_interrupt_handler.c" function, the "_ux_device_stack_disconnect()" function is called when the device enters the "SUSPEND" Mode. This mode occurs after a while on the USB bus. Or when the PC is put into sleep mode - and it is easier to check. Just put your PC to sleep and that's it. And already when it comes back out of this "SUSPEND" Mode, then no activation occurs again and the device no longer works and you need to add it somehow and I don't know how yet. In addition, as I wrote earlier, only certain addresses at the endpoints (only those values that are now in the examples) and the sizes of the send / receive buffers work. This is due to the incomplete programming of the USB registers. Perhaps the default values (after the reset state) are only here in them, and the required values will not be adjusted. I am not such a good specialist in programming USB HS (FS) controller registers and I do not know exactly how to fix it, but there is not the correct work here. I have already figured out how to fix something, but not yet completely.
As for the submodules in the github - thank you very much for the information and did not know that this is possible! But it turns out that it will still not be possible to implement it all together, since there will not be any pieces of code in the project for a specific controller (STM32 for example) unfortunately. There is no such external repository from Azure RTOS libraries for some controller, but only a universal version.
Hi @AleksBak, we will look into the SUSPEND mode issue. For your other issue regarding invalid transfers, can you give us an example file that shows the incorrect behavior? Right now, we do not know what buffer addresses or buffer sizes you are using that trigger the incorrect behavior, so please send us an example so we can test it.
Hi @nisohack.
Well, look - I sent you the same example that you sent me. Sorry that it is a little long, but it seems to me that it will not cause any difficulties in understanding it.
For convenience, you can use the following commands for IDE (I use STM32CubeIDE):
"Toggle folding" - keys "Ctrl + Numpad_Divide" and "Collapse all" - keys "Ctrl + Shift + Numpad_Divide".
I modified this example and added macros to make it easier to change the parameters for the endpoint descriptors.
And now, if we change such parameters for the descriptors:
#define CDC_DATA_HS_MAX_PACKET_SIZE 64U
for such values:
#define CDC_DATA_HS_MAX_PACKET_SIZE 512U
then the example will not work in the end. And it should, and for example, it works for ST.
This is due to incomplete programming of USB registers.
Above, I wrote to you about incorrect work with endpoint addresses - when not all values work. But here it still works correctly, and for example, if you apply such values in this example, it will work:
#define CDC_EP_CMD_IN_ADR 1
#define CDC_EP_DAT_IN_ADR 2
#define CDC_EP_DAT_OUT_ADR 3
All the above values are set in the "ux\usbx_device_controllers_ux_dcd_stm32_endpoint_create.c" function. And here is the problem.
Thank you very much for your support.
sample_usbx_device_cdc_acm.zip
Hi @AleksBak,
Thanks for the example. I was able to reproduce the issue. We are currently looking into it and will let you know what we come up with.
Thanks,
Nick
Hi @AleksBak,
Please replace your ux_dcd_stm32.h with this version: ux_dcd_stm32.zip. It increases the FIFO size to support 512 byte MPS (Max Packet Size).
Also, if you send data that has a size that is a multiple of the MPS, then you will need to send a ZLP (Zero Length Packet) by calling _ux_device_stack_transfer_request with zero for the slave and host size parameters.
Thanks,
Nick
Hi @nisohack.
Thank you very much for your help!
Once again you helped me and at the same time surprised me again. I thought the problem here was in the wrong setting of the USB registers for the STM32 for the endpoint (for example, DIEPCTLx for the corresponding endpoint), but how much I don’t compare it with the USB library from STM, there’s no difference. And here it turns out it was necessary to set up in another place. I will continue to study and test here. Thank you so much.
I'll close this now but feel free to open again if you have more issues.