cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F429ZI bricked (SPRMOD bit raised)

Aurélien f
Senior
Posted on November 20, 2015 at 11:00

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
0 REPLIES 0