cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F745 dual CDC problems

MDJ
Associate II

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:

  1. When two VCOM ports are used one is working fine while the other doesn't work at all (the one that is meant to send data to MCU and read it back is working, while the other one that is meant to only read data from MCU is not working at all, it is enumerated but no data can be read from it).
  2. While the one VCOM port is woking it doesn't work with 100% success rate to put it simply like that. After some time the Qt app reports TimeoutError when trying to read data. Checking Wireshark logs BROKEN PIPE error is reported on IN endpoint for data.

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

5 REPLIES 5
gbm
Lead III

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).

My STM32 stuff on github - compact USB device stack and more: https://github.com/gbm-ii/gbmUSBdevice
Piranha
Chief II

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

MDJ
Associate II

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?

MDJ
Associate II

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.

MDJ
Associate II

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.