reliability of OTG USB on stm32f4 Disco

estie · ‎2015-09-07

Posted on September 07, 2015 at 09:51

I am intending to port GRBL Gcode interpreter to run on stm32f4 discovery and I have seen several reports that the OTG USB port ( more specifically the provided ST firmware ) is not reliable.

A colleague in the UK working with audio synth could not get reliable data transfer and moved to using USART where it worked as designed.

A partial port of GRBL to STM32 found similar reliability issues and adopted a similar solution.

Is this a known issue, is this the right place to raise it ?

Thanks.

#stm32f4-discovery-otg-usb

Nickname5522_O · ‎2015-09-07

Posted on September 07, 2015 at 11:57

Hi mouser,

Could you explain how the OTG USB port is not reliable? And what kind of reports did you seen?

-Shahrzad-

estie · ‎2015-09-07

Posted on September 07, 2015 at 23:11

Thanks for picking this up.

One instance was someone trying to port GRBL to STM32 . He did not provide much detail on the issues. He suggested that setting up a loopback would probably lock it up. Though he did not provide a proper test case.

https://github.com/deadsy/grbl_stm32f4

Another was a UK colleague who was working on audio and was unable to get send his synth audio data via CDC. I could try to get more details of the problem but he's not very communicative. I'll see what I can find. He also opted to use USART and said it was fine.

Now I have someone from ST on the case, I'll try to get more specifics.

estie · ‎2015-09-07

Posted on September 07, 2015 at 23:15

The CDC audio case was only giving data rates about two orders of magnitude slower than USB ''full speed'' , IIRC.

sirmanlypowers · ‎2015-09-08

Posted on September 08, 2015 at 15:31

I'm the author of the repo to which mouser is referring.

I wanted to use the USB CDC functionality as a serial port.

I derived from the CDC code in the STM32cube SDK.

It works- for a short time. The serial port locks up after a few minutes of moderate to heavy throughput. I assume the issue is in the USB driver code which is unmodifed from the SDK. Also - the use of a timer ISR on the Tx-side seems really hokey. I can understand how you want to accumulate bytes on the Tx- but a one shot would be a better solution than a periodic.

Here's the code:

https://github.com/deadsy/grbl_stm32f4/blob/master/board/usbd_cdc_interface.c

estie · ‎2015-10-26

Posted on October 26, 2015 at 11:44

Is this a recognised issue?

I would have thought that the central reference point for how program the CDC port would be the ST's SDK. Yet it seems that this is not well written and poorly tested.

The STM32 boards are powerful and supplied with some nice DSP software. The demo boards are designed to enable developers to determine whether they fulfil project requirements.

If the supplied driver code for USB CDC port does not work reliably, except for trivial I/O loads neither the demo products not the SDK are fulfilling their primary function.

It seems rather poor that ST can not write simple IO routines for their own hardware. Is this something that is likely to get attention?

Thanks.