DFU on an MUSB-based controller (MSPM0)

[Vinamra-TI]

Operating System

Linux

Commit SHA

3a0

Board

MSPM0G5187

Firmware

Sorry this is my first time creating issue here, please respond if i need to provide something else.

What happened ?

While using DFU via TinyUSB on an MUSB-based controller, DFU_UPLOAD intermittently fails after one successful upload. The failure occurs specifically when the host issues a DFU_GETSTATUS request immediately after a DFU_UPLOAD transfer.

This results in:
• Device no longer responding to GETSTATUS
• DFU state machine getting stuck
• Subsequent DFU operations failing until reset

How to reproduce ?

These are the steps:
• Device completes an IN data stage (DFU_UPLOAD)
• MUSB auto-ACKs STATUS OUT
• Host immediately sends the next SETUP packet (DFU_GETSTATUS)

At this point:
• _dcd.status_out is still set
• A new valid SETUP packet is already present
• The driver incorrectly interprets the new SETUP as STATUS handling and drops it

This causes GETSTATUS to never be processed.

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

NA

Screenshots

When i change this highlighted OR condition to AND condition , everything is working fine without status request getting stuck after upload request.

I have checked existing issues, discussion and documentation

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

[HiFiPhile]

Hi, I'm a little confused about the cause. Both DFU Upload and GetStatus are control IN transfers just like get descriptors, unless there is a racing condition which makes one work but not another.

• _dcd.status_out is still set
• A new valid SETUP packet is already present
• The driver incorrectly interprets the new SETUP as STATUS handling and drops it

Setup packet is received in dcd_int_handler() -> process_ep0() -> process_setup_packet, the device is always ready to receive Setup packet without needing dcd_edpt_xfer.

tinyusb/src/portable/mentor/musb/dcd_musb.c

Line 449 in 8a246db

if (req == REQUEST_TYPE_INVALID) {

[hathach]

I don't have MSPM0G5187 and it is not one supported MCUs. Can you confirm the issue also occur with tm4c123. For the issue detail: please update 1st post with

• complete commit hash
• firmware: we will need an example that run on mcu, I guess you are runing dfu examples, if you have modification, please provide the minial example that could cause the issue.
• "how to reproduce": which specific command or testing to trigger the issue