cancel
Showing results for 
Search instead for 
Did you mean: 

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.

Attachment is a complete log from STM32CubeProgrammer for Rev.V, and relevant OB settings.

0 REPLIES 0