ChibiOS Free Embedded RTOS

Hello,

First of all, it's not really a bug since the OTGv1 driver of ChibiOS does what it should.
The problem is that I discovered at least Windows 7/10 and Ubuntu 16.04 don't appear to follow correctly the USB bulk transmission protocol while working on our implementation of an onboard programmer for the e-puck2 educational robot made by us at the EPFL.
It took me some time to understand why my communications were not working in some specific cases. After catching the USB frames with Wireshark and a physical USB analyser I found out they (windows and Ubuntu) don't send a ZLP (Zero-length packet) when a communication is terminated with a maximum length packet (64 Bytes for an STM32 with USB FS). It means that the USB state machine of the STM32 USB peripheral is stuck forever waiting the end of the transmission because it thinks it's not over.

Maybe I missed something but from what I know, the condition to have a bulk transmission finished is either having received the maximum number of bytes the endpoint can receive (that's one trigger for the STM32), either having received a packet with less than the maximum packet size. It's why when the last packet has a size of 64 bytes, the computer should send a packet with no data to notify the transmission of datas is finished. Something interesting about this is that MacOS is doing it correctly and the problem doesn't appear whit it. ChibiOS too sends the ZLP when needed.

I implemented an ugly workaround for my code which adds a timeout when we receive a packet of size 64 Bytes and if we receive nothing after it, then it triggers the _usb_isr_invoke_out_cb() to let the USB SERIAL driver read the datas. I don't really see another way to do it since we need to handle something that should not happen.

- I tested it on ChibiOS stable 18.2.x
- Compiler : arm-none-eabi-gcc 7.2.1
- Platform and board : Tested on a Nucleo F746 and on a F413 on the e-puck2 robot
- Problem : In specific cases, the code don't receive the data since the OUT transmission is not considered as finished.

I don't ask you to change the OTGv1 driver immediately, the problem is solved on my side. It's just to let you know this problem exists and can block some USB communications in some specific cases.

Thank you
Eliot Ferragni

Hi,

The behavior of the OTG peripheral is that a transaction is over when 1) All requested bytes have been received or 2) a zero size packet has been received.

Your workaround of just calling the callback is probably problematic because from the OTG point of view the transaction is still ongoing. I am not yet sure about how this should be handled.

You could try to use the USB API directly without the buffering system, see the "USB RAW" demo under \testhal\STM32\STM32F7xx\USB_RAW, use the API to read exactly the size of a packet, this should avoid the problem but performance would not be great.

Giovanni

bump

Any comment regarding this issue? It does not look like a driver problem but probably some workaround could be possible.

Giovanni