RDP level1 is automatically SET on STM32F407 ! STRANGE ISSUE!

[moez]

Posted on October 16, 2014 at 17:32

Hi all,

I have a very strange issue with STM32F407ZG; sometimesthe RDP level 1 is automatically set and then using STLink Utilities I can goback to RDP level 0.BUT, Now I get RDP level 1 SET and I can't go toRDP level 0 : Seems to be Irreversible (like RDP level2).I can connect with STLink utilities, to read theoption bytes and I see RDP Level1 and I'm not able to modify it to go to RDPlevel 0.Canany one help please ? it is urgent!Thx,Franco #stm32f4 #rdp-level-1

[chen]

Posted on October 16, 2014 at 17:54

Hi

RDP - read out protoection?? Are you writing to the option bytes in your program? We found that if the processor is powered down during Option byte write - it corrupts the option bytes (unsurprisingly). We disabled the option byte write during normal code operation and the issue went away for us. (We now update the option bytes during a firmware upgrade, where powering down will corrupt things anyway!) Any help?

[moez]

Posted on October 16, 2014 at 18:01

Hi,

Indeed, Yes RDP = Read out protection.But, in my case I'm not doing any write to theoption bytes in my code!!Do you have other suggestions please ?

[chen]

Posted on October 16, 2014 at 18:08

We we first had this problem, we were getting code wiped as well as the RDP bit changing.

When we first had the problem, we were changing the IO pin configurations including the pin config for the debug (SWD or JTAG) during the boot up process. At this stage we were not writing the option bytes during operation. We changed the boot up process so that only the IO pins that are in use get changed, all the other IO pins are not left in their default state (including the debug port). This improved things but we still got the occasional code wipe.

[Tesla DeLorean]

Posted on October 16, 2014 at 18:53

If you have an unreliable SWD/JTAG connection via the ST-LINK all kinds of odd behaviour can manifest.

In some cases the USART based System Loader can be used to recover devices, and as I recall Segger had a specific application for their J-LINK.

[moez]

Posted on October 17, 2014 at 09:50

Hi clive1,

Still not solved using the USART boot loader !!I think it may be a quality issue on this device??

anyhelp?

[Tesla DeLorean]

Posted on October 17, 2014 at 14:15

anyhelp?

Not really getting a sense here about the board, chip, or conditions leading to this problem

[elliott]

Posted on October 28, 2014 at 21:32

We are also having this same issue, apparently. We are using an STLink-V2 debugger with an STM32F407 chip via the SWD interface. On one of our two production boards, we have encountered this issue. The following sequence does not work, and the RDP level remains at level 1:

1. Unlock FLASH_OPTCR by writing the correct sequence in FLASH_OPTKEY
2. Set RDP level 0 in FLASH_OPTCR by setting RDP byte to 0xAA
3. Set OPTSRT bit high in FLASH_OPTCR

After following these steps, the value of FLASH_OPTCR returns to what was originally there, with RDP level 1 set.  One possibly strange thing is that the value of the RDP bits is 0xFF.

This is perplexing us; I have seen similar behavior before, but it was due to a bug in OpenOCD (

http://openocd.zylin.com/#/c/2155/

).  This is not the same thing.

[Tesla DeLorean]

Posted on October 28, 2014 at 21:52

And is this something occurring with OpenOCD now, or ST-Link Utilities? Can you replicate the issue with code running natively on the part?

Are you able to run other code in the part? Can the issue be replicated with the Flash Loader Demonstrator, or otherwise, via the serial port and System Loader?

[Amel NASRI]

Posted on November 04, 2014 at 14:53

What leads to have the RDP level set to 1 at the first time before trying to remove it? 

You are also unable to go back to level 0 using ST-Link Utility?-Mayla-