ChibiOS Free Embedded RTOS

Hi.
While working with RusEFI project we have found that sometimes we get communication errors while working with PC tool over USB interface. We are using ChibiOS implementation of CDC ACM interface to emulate serial device. So PC tool works with our device as with serial device.
Sometimes during uploading a lot of data communication freezes for few seconds and protocol error is detected.
Log digging shows that issue happens when application sends 64 bytes packet.
Long story goes short - after few days with USB analyzer and debuger I decided to reproduce same problem with default CDC ACM demo.

ChibiOS from github master (acc9fb63bc4c1ea4644296deb8dc04e9b92ee15a)
Board: STM32F429I-DISCO
Code: RT-STM32F429-DISCOVERY example.
Host OS: Linux (but also reported as reproduced on Windows)
Steps to reproduce:
1. Run demo, wait for USB enumeration. /dev/ttyACM0 appears.

2. Write some random data to device using dd:
dd if=/dev/urandom of=/dev/ttyACM0 count=1 bs=63
No issue.

3. Write exactly 64 bytes to device using dd:
dd if=/dev/urandom of=/dev/ttyACM0 count=1 bs=64
If you are lucky and this write happens with single USB transaction then you will see:

And timeout counter will increase by 1:


What I also found:
1. If i set SERIAL_USB_BUFFERS_SIZE to 64 (equal to EP size) this issue is not reproduced.
2. Data is actually received by device but with a loooong delay. It seems to me that data is stuck somewhere in internal buffer (or HW?) and finally poped when another packet (!= 64 bytes) is received.
What I observe in PC tool log is it tries to send this 64 bytes chunk two times with 3 second timeout, then app restarts communication process, sends some "who are you" request and at this point our device receives all three packets.

I have few STM32 based devices, Total Phase USB analyzer and some time I'd like to spend on this bug. So any suggestion on what else I can try are welcome.

May be somehow related to zero length packets (ZLP)? Also viewtopic.php?f=25&t=4568&p=32429

Does this reproduce on an STM32H7? It uses a different USB IP and driver.

mck1117 wrote:Does this reproduce on an STM32H7? It uses a different USB IP and driver.

Did not try yet, but this is a good idea.
BTW I also have AT32F437, which uses the same driver but China-authored USB IP.

Dron_Gus wrote:May be somehow related to zero length packets (ZLP)? Also viewtopic.php?f=25&t=4568&p=32429

Hi, this was apparently fixed by that change. Will try to reproduce over weekend.

Giovanni

Dron_Gus wrote:1. If i set SERIAL_USB_BUFFERS_SIZE to 64 (equal to EP size) this issue is not reproduced.

Nope, I was wrong. SERIAL_USB_BUFFERS_SIZE = 64, issue is still exist.

It is also possible to use the USB "RAW" API without buffering, it would be interesting to know if the issue is still there without USB_Serial. There is one example application: STM32F7xx-USB_RAW

Giovanni

Data stops stucking in USB internals after implementing loop in IRQ and reordering RXFIFO management and IN/OUT EP handling like it is done in Linux kernel: https://github.com/torvalds/linux/blob/ ... et.c#L3719
Now EPs are handled first, then Rx FIFO.
But USB sniffer still shows this 64-bytes transaction as time outed.

Hi,

Could you post your changes?

I tried using the low level API an it works using any packet size, it could be something related to buffering. What I am seeing however is very low performance, the transfer rate is like 1KB/sec regardless the buffer size but probably this is related to the synchronous API.

The new demo is under /testhal/STM32/multi/USB_RAW, it supports most STM32s. I will continue looking for the problem.

Giovanni

There is definitely something wrong with OTGv1, it fails with any buffer size greater that 64 here and then the debugger disconnects, very strange.

I will make some regression tests to see if it started to behave this way after some change.

Giovanni