Skip to content

Conversation

@kasjer
Copy link
Collaborator

@kasjer kasjer commented Sep 24, 2021

Describe the PR
Windows and Linux host during enumeration requests device
descriptor with request size set to 64 bytes when device
was in default state (no address).
Those systems do not want 64 bytes though since usb descriptors is
only 18 bytes long so they silently expect that only one packet
will be received possibly 18 bytes for EPS > 16 or 8 or 16 bytes
for smaller EP0.

For devices with CFG_TUD_ENDPOINT0_SIZE size 8 or 16 there was
workaround that reduced request size to CFG_TUD_ENDPOINT0_SIZE
and that was enough to satisfy Windows and Linux hosts.

However USBCV testing application also requests device descriptor
but with size set to 18 bytes. Workaround for Window/Linux
prevented USBVC to tests devices with 8 bytes EP0 size since it
send only 8 bytes while application did wanted 18 bytes.

Solution that satisfies both cases it to check if in default state device
descriptor request wants more bytes than descriptor size (18).
If so host is expecting to receive less bytes then requested
and workaround would be applied since Linux/Windows only try
to read one packet.
If 18 bytes was requested as is the case for USBCV, core returns
descriptor in 2 or 3 packets as application expects.

Windows and Linux host during enumeration requests device
descriptor with request size set to 64 bytes when device
was in default state (no address).
Those systems do not want 64 bytes though since usb descriptors is
only 18 bytes long so they silently expect that only one packet
will be received possibly 18 bytes for EPS > 16 or 8 or 16 bytes
for smaller EP0.

For devices with CFG_TUD_ENDPOINT0_SIZE size 8 or 16 there was
workaround that reduced request size to CFG_TUD_ENDPOINT0_SIZE
and that was enough to satisfy Windows and Linux hosts.

However USBCV testing application also requests device descriptor
but with size set to 18 bytes. Workaround for Window/Linux
prevented USBVC to tests devices with 8 bytes EP0 size since it
send only 8 bytes while application did wanted 18 bytes.

Solution that satisfies both cases it to check if in default state device
descriptor request wants more bytes than descriptor size (18).
If so host is expecting to receive less bytes then requested
and workaround would be applied since Linux/Windows only try
to read one packet.
If 18 bytes was requested as is the case for USBCV, core returns
descriptor in 2 or 3 packets as application expects.
@kasjer kasjer requested a review from hathach September 24, 2021 12:20
Copy link
Owner

@hathach hathach left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

look great, thank you for your PR. Test with MP430 port, but it seems to break somewhere.

@hathach hathach merged commit 958cf2c into hathach:master Sep 25, 2021
@kasjer kasjer deleted the kasjer/usbd-small-ep0-enumeration-workaround branch September 25, 2021 22:50
@DatanIMU
Copy link

DatanIMU commented Oct 3, 2021

I have similar issue.
I use STM32F103 BLUEPILL board, Win10-PC-Host send usb packet ( 80 06 00 01 00 00 12 00)
However, I use another MCU IC manufactured by Chinese facturary ( they said it is as the same as the STM32F103C8T6 except vendor id register and deviced ID). after power on, during usb enumeration ,Win10-PC-Host send usb packet ( 80 06 00 01 00 00 40 00 ). my board still response 18bytes.

then issue happen!

@hathach
Copy link
Owner

hathach commented Oct 3, 2021

@maemoKKK it is not the same issue, please open your own one with detailed information to troubleshoot, And don't spam on others.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants