Can I change endpoint size from 64B to 128B for USB2.0 FS device CDC class ?

[JSHAR.1890]

I’ve modified the firmware code generated out of STM32CUBEMX the endpoint size change from 64B to 128B. Since this change is in the firmware, the Host driver will read this value from the Device descriptor (during enumeration) and ensures that the driver receives and transmits max of 128B. Though it is against the USB2.0 FS standards which recommend max of 64B, what could be the impact and issues. So far I've tested with short packets and upto 128B, it works seamlessly correct without packet or data loss.

[Uwe Bonnes]

As I understand, the host use endpoint size to determine if it is a low/Full/High speed device. This detection is part of the host os, and things may turn out different if you check on another OS/OS-Version.

[Bob S]

I recall seeing posts where either people tried increasing the endpoint size, or CubeMX had improperly set the endpoint size greater than 64 bytes and the USB interface wouldn't enumerate. Changing to 64 bytes fixed that. Which goes along with what @Uwe Bonnes​ said above. Forum searches fail me right now or I would point you to the old posts about endpoint size.

[waclawek.jan]

My car manufacturer states that its maximum load is 300kg. I put 500kg of rebars into it and it worked. How far can I go with this? What might go wrong?

JW

[JSHAR.1890]

Thanks.

[JSHAR.1890]

I've set the endpoint to 64B.

When I send data (say 100B) from host, the CDC firmware always receives two packets (64B and 36B) back to back. Hence the firmware must manage the data packets received.

But when I send say 100B of data from the firmware, the host receives full packet without any break. Does the USB firmware stack manages the packets that are sent to the Host? or should the firmware manage the data packets transmission similar to receiving?