USBD_ClrFeature does not handle HALT condition per USB specification

[jmgurney]

Caution
The Issues are strictly limited for the reporting of problem encountered with the software provided in this project.
For any other problem related to the STM32 product, the performance, the hardware characteristics and boards, the tools the environment in general, please post a topic in the ST Community/STM32 MCUs forum.

Describe the set-up

• Heltec Node151: https://heltec.org/project/lora-node-151/

$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Describe the bug

When using the USB CDC code w/ FreeBSD, FreeBSD issues a ClearFeature(HALT) in order to initialize the data toggle bit. When this happens, the USB HAL library stops responding and no more usb communications happens.

On other platforms which do not do this step, like MacOSX, things work fine. If I add a delay before the first IN command (write data to the host), it works fine on FreeBSD. I'd expect that when a halt happens like this, that any pending transactions be restarted, and the data be successfully sent. In my case, data never gets sent from the micro to the host.

How To Reproduce

1. Aquire and compile the code: https://www.funkthat.com/gitea/jmg/lora-irrigation

2. There are a number of strings that are printed out when first attached. This data does not appear on FreeBSD.

3. This appears to be missing code handling the ClearFeature(HALT) which is required per the USB specification.

4. Just connect it to a FreeBSD host.

5. Run a generic CDC endpoint, on a device, and connect it to a FreeBSD host.

Additional context

Screenshots

This screenshot shows the results of running a USB analyzer. Without a delay, and connecting to a FreeBSD host, you can see that there are a couple clear endpoint features to HALT (to initialize the data toggle to a known state) the IN and OUT direction of the EP. The micro does not recover and stops sending all data. It also fails to receive data, but this could be because it hasn't processed the incoming data yet.

[ALABSTM]

Hi @jmgurney,

Thank you for this report. We will get back to you with a feedback as soon as possible. Please excuse the delay it may take us sometimes to reply. Thank you for your comprehension.

With regards,

[ALABSTM]

Hi @jmgurney,

I hope you are fine. Your point has been forwarded to our development team for further analysis. Would you mind attaching the trace file shown on the screenshot above?

Thanks,

[ALABSTM]

ST Internal Reference: 126921

[jmgurney]

Sorry, I did not save the trace, so I cannot attach it. If I get around to recreating the trace, I will, but it's clear that the code to handle the above case is missing, so I don't know what additional information you need from the trace to deal w/ the issue.

[ALABSTM]

Hi @jmgurney,

No additional info needed for the moment. If you ever recreate the trace, please do not hesitate to send it. In the meanwhile, we will try to refer to the screenshot.

With regards,

[ALABSTM]

Hi @jmgurney,

Unfortunately, our development teams could not reproduce the issue you reported as they have no access to a FreeBSD host.

However, they ensure the clear feature is well supported by ST's USB library and that it clears the stall condition, as per the specification.

Hence, they consider there is no issue to fix. Please allow me to close this thread in this case. Thank you for your comprehension.

With regards,

[jmgurney]

Could you point me to the specific code in the tree where this code is implemented? Because as I don't have access to an emulator, it is very hard to trace down the code where this is a problem.