Posted on November 20, 2015 at 11:00Hello,
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 WDGw4 0x40023c14, 0x0FFFAAECw4 0x40023c14, 0x0FFFAAEEw4 0x40023c14, 0x0FFFAAED// Reset the core so that changes are taken into accountrWhen 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
