USBX CDC ACM data read bug?

[tec683]

This behavior seems like a bug.

I’m using USBX CDC ACM on a H723 nucleo board. I’m trying to work with the blocking nature of the ux_device_class_cdc_acm_read. For my application, I would like to get data as soon as up to 256 characters are received but the length will be variable. I’ve tried a few things and found this behavior that seems wrong. My application currently just loops back any strings received.

The endpoint is set to 64 bytes. That was the setting from the example and seems ok. I’ve set the requested_length to 256 and have a buffer allocated to this. This is 4 times the size of the end point.

I’m using Hterm 0.8.9 on Windows 10.
STM32CubeIDE 1.13.2, STM32CubeMX 6.9.2-RC4, STM32Cube MCU Package for H7 1.11.1, X-CUBE-AZRTOS-H7 3.2.0.
ThreadX and USBX is 6.2.1.

When I send a 63 byte string, the read call returns with a length of 63. Data and length are good.

When I send a 65 byte string, the read call returns with a length of 65. Everything is ok.

However, when I send a 64 byte string, the call does not return. I am monitoring the USB traffic with a Beagle 480 USB protocol analyzer. I get an error T which is “Capture for transaction timed out while waiting for additional data.“ If I send an additional single byte, the read call returns with 65 characters. The original 64 and the additional byte.

This certainly seems like a bug as it works at 63 and 65 characters and doesn’t return at 64.

The attached PDF of this has capture information.

[mohamed.ayed]

Hi @tec683 ,

Thanks for reaching out ST community.

could you please confirm that this flags UX_DEVICE_CLASS_CDC_ACM_WRITE_AUTO_ZLP  is defined in ux_user.h in your project ?? 

[Pavel A.]

The host does not send ZLP.

@tec683 Have you installed any special driver on Win10 for the USB serial port or Windows automatically recognized the CDC ACM device?

[tec683]

I am using the standard Windows serial driver that is installed by default ie no special INF file or anything.

Yes,  UX_DEVICE_CLASS_CDC_ACM_WRITE_AUTO_ZLP is enabled in the IOC and defined in ux_user.h file. Though reading the comments, this just seems to affect the write behavior and not the read where I'm seeing what seems like anomalous behavior. 

[Pavel A.]

Try another terminal program. Teraterm.

[tec683]

I see the same behavior with Teraterm. I would think the Windows CDC ACM driver would be the main cause of behavior which will be the same across different terminal programs.

[Pavel A.]

The Windows driver works for millions of users, every day, with thousands of device models. I cannot figure out why the ZLP is not sent, even with different host applications. Suggest to re-check your endpoint descriptors.

[tec683]

I didn't say the windows driver was doing anything incorrect.  Just that the terminal program selected was not likely to matter for a low level issue such as I am describing. The terminal programs likely just take the input string and sends it to the COM write function call.  So the behavior is likely the same between programs.

To your point that the windows driver is likely correct, the problem is more likely in the STM32 firmware. As a practical matter, even if we could somehow prove the Windows USB serial driver was doing something incorrect, the device implementation would have to work around what ever the behavior is because it certainly is not practical to expect all the deployed Windows copies to change anything. 

I'm new to USB and specifically USBX. In another unanswered post, I could not get the USBX CDC ACM to work on an F7 series processor.  I had success on an H723.  But even on the H723, I found the behavior described here.  I'm hoping that someone much more knowledgeable than me on STM32, USB, and USBX could explain this behavior in more detail.