verifying the size.
As noted in PR #2512 simply verifying the size of the hex file is not
extensible and is not how hex files are designed to be used.
A hex file can contains many non-contiguous blocks of data.
This also supports targets with any partition layout.
Additionally, this provides a more flexible way of providing hex files
which can now contain data for non-contiguous blocks, e.g. firmware +
config or firmware + osd fonts.
The error check after attempting to claim the USB interface was falsely indicating failure on MacOS even though it was working properly. Tried all available versions of NW.js (including beta) and none resolve the problem. The problem only seems to affect MacOS.
The error check after claiming the interface is suppressed for MacOS to work around the problem. Risk is low because even if the climing of the interface failed the worst that could happen is flash fails anyway.
Hopefully there will be some future version of NW.js that resolves the problem and we can remove this workaround later (tested through 0.45.0-beta1 so far).
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.
