← index #5693PR #7410
Related · medium · value 3.043
QUERY · ISSUE

[mboot] It will stay in the dfu mode forever and not reset

openby rolandvsopened 2020-02-24updated 2025-11-09
port-stm32needs-info

When using mboot to replace the code with dfu commands all works fine. However, mboot stays in dfu mode and not resetting the device. This is tested using mboot with the H743.

CANDIDATE · PULL REQUEST

stm32/mboot: Add verification to fsload / dfu support

closedby andrewleechopened 2021-06-17updated 2022-03-22
port-stm32

This PR extends the fsload support in stm32/mboot which is used to flash a dfu file stored on an internal filesystem.

  • Add CRC check for all dfu files before starting to erase/write.
  • Add signature check for entire packed dfu files before starting to erase/write.

Background

I'm running into an intermittent issue when using mboot fsload support, where my app saves a dfu file to an LFS2 partition before handing it over to mboot to flash. I'm using the packed (signed/encrypted) dfu files.

In our application code I verify the crc in the dfu file after it's written to flash, before starting mboot with the details for the location of the dfu file. As such I know the file is initially transferred and stored correctly.

Most of the time it works, but under certain circumstances mboot fails part way through, it validated and flashed the first few chunks in the dfu file, then gets to one it rejects due to it not matching the signature.

This particular dfu is not holding firmware, but in fact is targeting a separate partition in an external flash. As such when it fails, the firmware itself is still intact and the device will happily reboots back to application code. Interestingly the partition the DFU file was stored in now reports it cannot mount, so that partition has been corrupted somehow. It all sounds like there's a problem with the address / partitions / overlap / erase or something - but the intermittent nature of this is making it hard to track down.

In the process of diagnosing the root cause of this problem, I noticed the CRC check in fsload was never implemented, so that has been added here in one of the commits.

fsload already had a two-pass approach to handling dfu files, it'd read/walk through it first to check the dfu structure is correct, before resetting the file pointer and read/walking through it again to flash.
The second change included here is to extend this first pass for packed files to also run the signature check on each section, therefore checking the signatures on the entire file match before it starts erasing/flashing anything.

Keyboard

j / / n
next pair
k / / p
previous pair
1 / / h
show query pane
2 / / l
show candidate pane
c
copy suggested comment
r
toggle reasoning
g i
go to index
?
show this help
esc
close overlays

press ? or esc to close

copied