H743 Rev.V (probably other H7 Rev.Vs also) remains in dfuDNBUSY state after the specified delay time.
STM32CubeProgrammer deals with behavior with an undocumented procedure as follows.
1. Issue DFU_CLRSTATUS, which ends up with (14,10) = (errUNKNOWN, dfuERROR)
2. Issue another DFU_CLRSTATUS which delivers (0,2) = (OK, dfuIDLE)
3. Treat the current erase successfully finished.
Here in this PR, we call clarStatus to get to the dfuIDLE state when dfuDNBUSY is detected after timeout.
---
Below is the complete description of the problem reported at ST community
(https://community.st.com/s/question/0D50X0000C0w7U9SQI/weird-stm32h743zi-revv-usb-dfu-erase-behavior-beyond-1mb-page-8)
Weird STM32H743ZI Rev.V USB DFU erase behavior beyond 1MB (sector 8)
Summary
I'm observing errors and what looks like a non-standard error recovery procedure for all sectors beyond 1MB (sectors 8 through 15) during sector erase on STM32H743ZI Rev.V (Nucleo-H743ZI2) under STM32CubeProgrammer.
Is this behavior documented anywhere?
Description
For sector erase start to sector 2 erase, a log from the STM32CubeProgrammer looks like this.
13:05:04:121 : Flash sector erase ...
13:05:04:121 : DFU status = 0
13:05:04:121 : DFU State = 9
13:05:04:121 : Status: 0, State: 9
13:05:04:121 : sending an abort request
13:05:04:122 : DFU status = 0
13:05:04:122 : DFU State = 2
13:05:04:122 : sending a page erase request @: 0x08000000
13:05:04:122 : data: 4100000008
13:05:05:025 : DFU status = 0
13:05:05:025 : DFU State = 4
13:05:05:026 : DFU status = 0
13:05:05:027 : DFU State = 5
13:05:05:027 : erasing sector 0000 @: 0x08000000 done
13:05:05:027 : DFU status = 0
13:05:05:027 : DFU State = 5
13:05:05:027 : Status: 0, State: 5
13:05:05:027 : sending a page erase request @: 0x08020000
13:05:05:027 : data: 4100000208
13:05:05:932 : DFU status = 0
13:05:05:932 : DFU State = 4
13:05:05:933 : DFU status = 0
13:05:05:934 : DFU State = 5
13:05:05:934 : erasing sector 0001 @: 0x08020000 done
13:05:05:935 : DFU status = 0
13:05:05:936 : DFU State = 5
13:05:05:936 : Status: 0, State: 5
...
I notice that sector erase requests are followed by what seems like a pair of GETSTATUS results, with (status, state) being (0, 4) and (0,5) and then declared as erase done.
States 4 and 5 are probably dfuDNBUSY and dfuDNLOAD-IDLE respectively.
All sectors within the first 1MB (sectors 0 through 7) behaves the same.
But for sectors beyond 1MB, it looks like this.
13:05:11:397 : DFU status = 0
13:05:11:397 : DFU State = 5
13:05:11:397 : Status: 0, State: 5
13:05:11:397 : sending a page erase request @: 0x08100000
13:05:11:397 : data: 4100001008
13:05:11:413 : DFU status = 0
13:05:11:413 : DFU State = 4
13:05:11:414 : DFU status = 0
13:05:11:414 : DFU State = 4
13:05:13:419 : sending a clear status request
13:05:13:421 : DFU status = 14
13:05:13:421 : DFU State = 10
13:05:13:421 : an error occured after sending the clear status request
13:05:13:421 : Status: errUNKNOWN, State: dfuERROR
13:05:13:421 : DFU status = 14
13:05:13:422 : DFU State = 10
13:05:13:422 : sending a clear status request
13:05:13:422 : DFU status = 0
13:05:13:422 : DFU State = 2
13:05:13:422 : DFU status = 0
13:05:13:422 : DFU State = 2
13:05:13:422 : erasing sector 0008 @: 0x08100000 done
Notice that GETSTATUS results are now (0,4) and (0,4), followed by CLEARSTATUS returning (14,10) which is attributed as dfuERROR, and then another CLEARSTATUS (may be two?) that returned (0,2). This particular sector erase process is treated as successful, but it looks like that the process has never confirmed the successful completion of the erase operation but forced clear an error caused by the preceding clear.
(status, state) in the process are probably:
(14, 10) = (errUNKNOWN, dfuERROR)
(0, 2) = (OK, dfuIDLE)
Btw, sector erase succeeds with (0,4) (0,5) on STM32H743ZI Rev.Y (Nucleo-H743ZI) for all sectors 0 through 15 under STM32CubeProgrammer.
There was previous logic in place to display a visual indicator for the status of the firmware flash using different colors for the progress bar. Unfortunately the logic was never working, or was broken at some point. The progress bar color would remain the default even if the flashing failed, making it difficult to recognize there was a problem.
Fixed to display the progress bar in green for success, red for failed, and blue for other "action required" types of failures. The logic was already there to try and display the red and blue indicators but they weren't working.
