Trying to run the command before installing results in
```
sudo xattr -rd com.apple.quarantine /Applications/Betaflight\ Configurator.app
Password:
xattr: No such file: /Applications/Betaflight Configurator.app
```
- Clear to in-memory ports array when reading MSP2_COMMON_SERIAL_CONFIG,
like MSP_CF_SERIAL_CONFIG does. Take the opportunity to move the
`SERIAL_CONFIG.ports = [];` statement to the very first line of both
handler blocks, so it's more evident.
- Remove accidentally duplicated line in the payload serializer
for MSP_SET_CF_SERIAL_CONFIG, which then I copied and pasted to
MSP2_COMMON_SET_SERIAL_CONFIG. This was sending the msp_baudrate
twice, causing all baudrates after it to be misinterpreted.
Fixes#1864
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.
Michael Keller
Asizon
Miguel Angel Mulero Martinez
Bruce Luckcuck
bluehallu
Alberto García Hierro
jflyper
Nicolas Vanhoren
Andrew Young