OUT direction ZLP causes corrupt transfer if DMA disabled (IEC-414)

[projectgus]

Answers checklist.

• I have read the component documentation ESP-IDF Components and the issue is not addressed there.
• I am using target and esp-idf version as defined in component's idf_component.yml
• I have searched the issue tracker for a similar issue and not found any related issue.

Which component are you using? If you choose Other, provide details in More Information.

device/esp_tinyusb

ESP-IDF version.

v5.5.1

Development Kit.

ESP32-S3 DevKitC

Used Component version.

tinyusb v0.18.0~4

More Information.

When DMA is disabled (CONFIG_TINYUSB_MODE_SLAVE is set), if the host sends an OUT zero length packet (ZLP) then TinyUSB receives a corrupt transfer (64 bytes instead of 0, with whatever was previously in the buffer).

This is most obvious for USB-CDC driver and MacOS host when transmitting a multiple of the endpoint size (64 bytes), but can be the case any time that the host sends a zero length packet.

A fix is already merged in upstream TinyUSB: hathach/tinyusb#3293 but it merged just after the upstream 0.19.0 release so may not be released for some time.

I'm not necessarily asking for it to be fixed early in the Espressif fork, but thought I'd report it anyhow.

[github-actions]

Hi @projectgus! Please be aware that the following suggestions are generated by a bot and haven't been fact-checked by Espressif Systems. We hope that this message will help you until an Espressif Engineer looks at your issue.

---

Thank you for reporting this issue. Based on the information provided and the knowledge sources available, I can confirm that this is a known issue with TinyUSB when DMA is disabled on ESP32-S3.

Issue Summary

When CONFIG_TINYUSB_MODE_SLAVE is set (DMA disabled), OUT direction zero-length packets (ZLPs) cause corrupt transfers. Instead of receiving 0 bytes, TinyUSB receives 64 bytes containing stale buffer data. This is particularly noticeable with USB-CDC on macOS when transmitting multiples of the endpoint size (64 bytes).

Current Status

According to your report, the fix has already been merged in upstream TinyUSB (PR #3293) but was merged after the 0.19.0 release. The knowledge sources show that the current Espressif TinyUSB component version is v0.18.0~6, which predates this fix.

Recommendation

Since you're using tinyusb v0.18.0~4 and the fix is in upstream TinyUSB but not yet in a released version that Espressif has integrated, you have a few options:

1. Wait for the next Espressif TinyUSB component update that includes upstream changes beyond 0.19.0
2. Apply the upstream patch manually to your local TinyUSB component if you need an immediate fix
3. Enable DMA mode if your application allows it (by not setting CONFIG_TINYUSB_MODE_SLAVE)

Your report is valuable for tracking this issue, and it will help ensure that the fix is included in future Espressif TinyUSB component releases.

[tore-espressif]

@projectgus Thank you for bringing it up. The fix is now part of tagged release 0.20.0 https://github.com/hathach/tinyusb/releases/tag/0.20.0

We will retest and release new version soon

[roma-jam]

Hi @projectgus ,

we released the espressif/tinyusb component with v0.19.0~2, that has several important fixes from the release 0.20.0 to make it more stable.

The related fix regarding the reported issue is also a part of it, so it is already available: https://components.espressif.com/components/espressif/tinyusb/versions/0.19.0~2/readme

The full description of these changes "above" the upstream 0.19.0 can be found in here, under the section "Changes":
espressif/tinyusb#69

The latest 0.20.0 has several limitations at the moment. We will release it asap.
To track the progress, please follow the espressif/tinyusb#73

I close the ticket as the issue is already solved by the available version.
Thanks for the report and do not hesitate to let me know if there is anything else.