Description
Describe the bug
I'm using the USB DFU class with MCUboot.
When both slots are defined in the DTS, the DFU implementation currently allows:
- Upload from both alt=0 (slot-0) and alt=1 (slot-1)
- Download only to alt=1 (slot-1)
Attempts to download to alt=0 are explicitly rejected in the DFU handler, resulting in a transfer failure:
>dfu-util.exe --alt 0 --download ....\build\zephyr\zephyr.signed.bin
dfu-util 0.11
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2021 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Warning: Invalid DFU suffix signature
A valid DFU suffix will be required in a future dfu-util release
Opening DFU capable USB device...
Device ID 1fc9:ffff
Device DFU version 0110
Claiming USB DFU Interface...
Setting Alternate Interface #0 ...
Determining device status...
DFU state(2) = dfuIDLE, status(0) = No error condition is present
DFU mode device DFU version 0110
Device returned transfer size 128
Copying data from PC to DFU device
Download [ ] 0% 0 bytes failed!
DFU state(10) = dfuERROR, status(3) = Device is unable to write memory
It seems that USB DFU permits downloads to only one slot, which appears logical since enabling both slots results in slot-1 being selected as the default target.
This restriction becomes a problem when slot-0 contains no valid image. In such cases, MCUboot fails with:
E: Unable to find bootable image
FIH_PANIC
Impact
Prevents USB-based recovery in cases where slot-0 is invalid, requiring physical access to reflash the device.
Zephyr version: v4.1