Potential issues with MIDI Host

[203Null]

Operating System

Windows 11

Commit SHA

7ddf631

Board

Custom CH32L103

Firmware

https://github.com/203Null/tinyusb/tree/l103 but without the 203Null@49e8cf1

What happened ?

I try to bring up CH32L103 support with USB MIDI host. During set up https://github.com/203Null/tinyusb/blob/7ddf63151d840d804ea16f6f27ad18619df3ec66/src/class/midi/midi_host.c#L329 is bring faulted.

I let AI to investigate and it produced 203Null@49e8cf1

I don't know the rest of the system well so I'm just raising it as a potential issue

How to reproduce ?

I honestly not sure if this can be produced on other platforms

Debug Log as txt file (LOG/CFG_TUSB_DEBUG=2)

[MIDIH] open: addr=1 itf=1 idx=0 itf_count=2
[MIDIH] set_config: addr=1 itf=0 idx=0
[Application Log] MIDI mounted: idx=0 addr=1 rx_cables=2 tx_cables=2
[MIDIH] set_config: addr=1 itf=2 idx=255
[Custom log that replaces the assert] MIDI set_config without open: addr=1 itf=2

Screenshots

No response

I have checked existing issues, discussion and documentation

• I confirm I have checked existing issues, discussion and documentation.

[sauloverissimo]

Hey, I hit the same issue while working with MIDI Host on ESP32-S3. My device has Audio Control (itf 0) + MIDI Streaming (itf 1), and set_config was crashing with idx=255.

I investigated and reached the same conclusion as @203Null. The problem is in the midih_open loop — when it finds the next interface and sets found_new_interface = true, the p_desc = tu_desc_next(p_desc) at the end of the while still executes, advancing one descriptor beyond. This inflates desc_midi_total_len, and tu_bind_driver_to_ep_itf ends up mapping the following interface to the MIDI driver. When the framework calls set_config for that phantom interface, tuh_midi_itf_get_index returns INVALID and the TU_ASSERT fails.

The fix by @203Null (wrapping the advance with if (!found_new_interface)) addresses the root cause. The second change in the mount callback (using p_midi->bInterfaceNumber instead of itf_num) is also correct — it ensures the callback receives the MIDI Streaming interface number rather than the Audio Control one.

Tested the patch and can confirm it resolves the issue.

[hathach]

thank you, pr is on the way #3556