2021-12-17 07:57 AM
Hello,
I have been testing modifications for STM32 default USB library stack that was modified to support dual CDC. The code is working fine on STM32H745 MCU. The idea was to now use this same library for F745 to communicate with Qt app on PC but there are some problems:
I am suspecting that there is some synchronization problem on F745 side when doing USB Tx and Rx. It would be helpful if someone has any experience regarding these two issues (it doesn't have to be related to F745).
Thank you
2021-12-19 12:00 PM
Make sure that Transmit is called only from an interrupt routine with the same interrupt priority as the USB interrupt. It will sooner or later fail otherwise (i.e. called from main function).
2021-12-19 05:22 PM
Don't waste your time on a broken bloatware designed by incompetent people... ;)
https://github.com/hathach/tinyusb/tree/master/examples/device/cdc_dual_ports
2021-12-22 07:36 AM
Transmit is indeed called from main function. It is interesting though that there are no problems on H745 board. USB comm never fails, neither transmit nor receive, but on F745 with the same CDC logic it can fail sometimes. Also, if the retry logic is added to desktop app, to try and communicate again, it works. Problem is that it should work always from the first try, retry logic is not really a solution. Do you have any comments on this?
2022-01-11 04:40 AM
Managed to find the solution for problem stated in point 1. of the question above. Since F745 has only 1.25KB of memory for Rx and Tx endpoint buffers, and H745 has 4KB, it was only a matter of modifying the sizes of buffers set by using functions HAL_PCDEx_SetTxFiFo and HAL_PCDEx_SetRxFiFo to not overflow the 1.25KB memory area. Still need to look into the problem 2.
2022-01-25 06:49 AM
Upon further inspection, for problem number 2. BROKEN PIPE error was reported in Wireshark logs on OUT endpoint first. The message was not coming to the MCU. And thus when Qt desktop app would wait for response it would timeout because there was no request for which to prepare the response. This was only occurring when using the USB Hub. When connected directly, bypasing the hub, it started working as it should.