Hello Aurélien,

We just gave it a quick try here using the ST STM32F4 Discovery kit (STM32F429ZI device on it) with software version V5.02k. We have activated the hardware watchdog through the option bytes (0x40023C14 = 0x0FFFAACD) but programming as well as erase still works fine. During flash programming, the RAMCode makes sure to feed the watchdog by writing 0xAAAA to the IWDG_KR, periodically.

I’m currently facing an issue during flashing an STM32F429ZI (Cortex-M4) with a J-Link (but not every time) [...] I have finally found why it returns an error. Actually, on STM32F429, there is a SPRMOD bit (in FLASH_OPTCR register) that enables or not read/write protection

Can you provide further information regarding this? How often does the issue pops up? We would expected that it does never pop up when SPRMOD bit is 0 (default) but everytime when SPRMOD bit is 1. Can you confirm this assumption?

and this bit has been raised and I don’t know why. But, I would like to know if someone has an idea about why this bit could have been raised. Am i doing something wrong ?

We are not aware of any bugs regarding this bit but we are pretty sure it is not set by the J-Link software or by chance (e.g. after watchdog trigger) because a special sequence is required to set the bit. The RAMCode itself and the J-Link DLL do not touch the option bytes at all. Therefore, we guess that it has been set by a "buggy" application or so running on the target.

Are you able to reproduce the behavior with the option bytes changed or did you see it only once?


Best regards
Erik

Just to make sure that we understand you correct here, you do not see any issues / errors during flash programming, correct? --> Watchdog seems to be fed correctly.

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 (maybe its the MCU itself that locks its memory to prevent any other modification but i don't let it recovering its original state)

I agree. Performing a reset immediately after triggering the option bytes programming may lead to unexpected behavior. Does adding a "sleep 100" before the reset, solves the behavior?

Right now, it does not sound to me like the watchdog causes any problems here but the sequence how the option bytes have been programmed.


- Erik

Hi All,

I've been having difficulty with the SPRMOD bit as well. This is a new bit in the STM32F427/429 chips that has some quirky behavior.

If I run JLink.exe 5.02 it sees that the part has read-protect bits set and tries to clear them (from 0xBB to 0xAA). The problem is that the SPRMOD bit in the options register is also set and it prevents the read-protect bits from being cleared.

In the STM32F4 manual, there's a section that says:

"The deactivation of the SPRMOD and/or the unprotection of PCROPed user sectors can
only occur when, at the same time, the RDP level changes from 1 to 0. If this condition is not
respected, the user option byte modification is cancelled and the write error WRPERR flag
is set. The modification of the users option bytes (BOR_LEV, RST_STDBY, ..) is allowed
since none of the active nWRPi bits is reset and SPRMOD is kept active."

I don't believe the JLinkSTM32.exe currently has the smarts to do the above procedure to clear out the SPRMOD bit.
I've even tried version 5.10 and 5.11(beta) to see if JLinkSTM32.exe clears it out, but it doesn't.

I've resorted to writing my own "unlock" .jlink file (see attached) that forces the read-protect bits to 0xBB and then writes the whole thing to 0x0FFFAAE1 (I like to set the BOR level). In the process, it clears out the whole program, but at least my board isn't bricked and is programmable.

Since JLink 5.11 is still in Beta, perhaps this issue can be fixed in the JLinkSTM32.exe script.

Cheers,
Tim

Hi All,


the next version of the STM32 Unlock Utility will clear the SPRMOD Bit on STM32 F42xxx/ F43xxx devices.
(And will introduce support for STM32F74xx and STM32F75xx devices )
A new version is planned to be available during the next week.

Best regards,
Niklas

Hello Niklas,

I just downloaded version 5.10h of the JLink.exe software that was released today.

If the option bits on an STM32F427 are set to 0x8FFFBBE1, the new JLinkSTM32.exe script properly resets all the option bits back to 0x0FFFAAED. Great!

HOWEVER: If the option bits are set to 0x8FFFAAE1, the new JLinkSTM32.exe script does nothing and leaves them at 0x8FFFAAE1.
If the SPRMOD bit is set (in all cases), I believe you need to set the read-protect bits to 0xBB before clearing both SPRMOD and the read-protect bits.

It also looks like JLink.exe has the older behavior of changing 0x8FFFBBE1 to 0x8FFFAAE1 on startup and erasing the part, but I'll start a new thread to address that.

Cheers,
Tim
nLIGHT Corporation

Hi Tim,

I believe you need to set the read-protect bits to 0xBB before clearing both SPRMOD and the read-protect bits.

actually, this is *exactly*, what we are doing. I will take a look at this.

Best regards,
Niklas

Hi Tim,


the update for STM32F42xx / 43xxx / 74xx / 75xx actually did not not make it into 5.10h, it will be included in the next release.

Best regards,
Niklas

Hi Tim,


the update is included in version 5.11b J-Link software & documentation pack (beta).

Best regards,
Niklas

Hi Niklas,

Thanks for the update. I'll give it shot (along with the SDK) and try it out.

Cheers,
Tim

Hi Niklas,

I've verified that JLinkSTM32.exe properly clears out the SPRMOD bit with the beta 5.11b version.
Thanks for fixing support for the SPRMOD bit on the STM32F42x/43x devices.

We can probably mark this one as SOLVED.

Cheers,
Tim