Problem with Flash memory Read Protection

This situation appear when from IDE uVision or directly from our application you are nloading your programo the flash (writing) and suddently the power is switch off because your input power is failted or another reason. At the next power on, the flash is in the state "Read Protection mode". In this situation in our case, is hastrofic

this makes no sense whatsoever
1) how often does the power cut off while you are downloading.
2) since you can download, a mass erase followed by a download will take care of it - hardly 'catastrophic'
3) I tried switching power off during a download to a stm32f103 and - lo and behold - the chip did not get read protected, I just repeated the download.

Erik

This situation appear when from IDE uVision or directly from our application you are nloading your programo the flash (writing) and suddently the power is switch off because your input power is failted or another reason. At the next power on, the flash is in the state "Read Protection mode". In this situation in our case, is hastrofic

this makes no sense whatsoever
1) how often does the power cut off while you are downloading.
2) since you can download, a mass erase followed by a download will take care of it - hardly 'catastrophic'
3) I tried switching power off during a download to a stm32f103 and - lo and behold - the chip did not get read protected, I just repeated the download.

Erik

Note, Erik, that a mass-erase will also remove any secondary boot loader that the user have added. And that secondary boot loader might be the only way to access the device for adding a new application.

So a mass-erase is a well working solution for a developer. But may not help with shipped devices.

So a mass-erase is a well working solution for a developer. But may not help with shipped devices
if, indeed, this happens at a "customer upgrade" I do see the issue.
however, out of curiousity I tried cutting power during a download of the same chip and nothing happened.

so,
a) verify sufficient decoupling, whatchdogging etc is in place, as I can not reproduce it.
b) contact ST directly for advise

Erik

Yes, I would think that it is common practice that the charge-pumps in the chips holds enough memory to perform one flash write operation on stored power, in which case the chip shouldn't end up in some random lockup state.

verify sufficient decoupling, whatchdogging etc is in place
I have seen strange effects from the above, e.g. I have seen an example where a 3cm trace to the decoupling cap was enough to cause problems. As a general rule, when someone exposes me to something unexplainable I ALWAYS check the decoupling and, if anything is not PERFECT, solder caps directly across the chips. this has "solved the unexplainable" more than once.

Erik

Hi,

Well at the end we are foud the problem, I 'm going to try to explian the most clear possibe.

First of all , we have three ways to programming FLASH memory into ST32M103RG:

- In Circuit Programming(ICP), with tha JTAG or SWD protocol
- In Application Programming (IAP), with differents communications channels like UART,USB, etc.., in this cas the CPU must to be in System Memory boot.
- With intructions in your applicattion like FLASH_ProgramWord, etc..

With the uVision IDE during downloading the program with JTAG or SWD, if you switch off the power supply, immediately the flash memory change to Read Protection State. The only way to disable the Read Protection is with the Load Flash Demonstrator Software from ST. After to disable the read Protection the FLASH memory is erased (mass erased).

In the rest of the cases if you switch off the power supply during the programming firmware, the Memory flash state don't change and doesn't happen.

You can try to do that...

Thanks for your help,

Xavi,