AnsweredAssumed Answered

STM32F429ZI bricked (SPRMOD bit raised)

Question asked by Aurélien f on Nov 20, 2015
Hello,

I am activating hardware watchdog (by using option byte). But sometimes, i need to deactivate this hardware watchdog, so I wrote some J-Link scripts to disable it before flashing or erasing my MCU. Unfortunatly, i have weird behavior regarding FLASH_OPTCR register when i do some modification. I follow the procedure indicated into reference manual. Here is my script:
// Read status of option bytes
mem32 0x40023C14, 1

// Unlock option bytes flash register
w4 0x40023C08, 0x08192A3B
w4 0x40023C08, 0x4C5D6E7F

// Check that the flash has been unlocked

mem32 0x40023C14, 1

// Deactivate HW WDG
w4 0x40023c14, 0x0FFFAAEC
w4 0x40023c14, 0x0FFFAAEE
w4 0x40023c14, 0x0FFFAAED

// Reset the core so that changes are taken into account
r

When i read memory at 0x40023C14, i obtain: 0xCFFFFFFD (i should have 0x0FFFAAED). I understand why some bit are raised (hardware watchdog is stopped, BOR level is ok ...) but others have a weird state, especially SPRMOD (bit31), DB1M (bit30) or BFB2 (bit4) ... Moreover, RDP (bit15 : 8 indicating read protect level is at level 1 !!!) When, i come to this state, my board is bricked (some flash regions are in read/write protection because of SPRMOD, and to recover my MCU i need to follow a particular sequence) -> I'm suspecting that i don't let enough time to the MCU when i'm updating FLASH_OPTCR register because i'm immediately doing a reset after the modification.

I'm also observing that doing a wait sequence just after modification of FLASH_OPTCR (before reset) improve behavior. But i don't know exactly how much do i need to wait. Do you agree with my analysis ? Do you htink i'm doing something wrong.

Best regards,

Aurélien

Outcomes