2015-03-07 03:12 AM
Hello to all,
I am using a STM32F2xx device. I need to set Readout Protection via the firmware itsself (not via JTAG). I use this code: if (FLASH_OB_GetRDP() == RESET) { FLASH_OB_Unlock(); FLASH_OB_RDPConfig(OB_RDP_Level_1); Buzzer = 1; FLASH_OB_Launch(); Buzzer = 0; FLASH_OB_Lock(); } When I execute the code it hangs within FLASH_OB_Launch(). I checked this not with a debugger but with a buzzer that beeps continously (see the code) I even transferred the whole routine to RAM, to avoid issues with the flash being busy and code has to be read at the same time from flash. -> Still hangs in FLASH_OB_Launch(). However when I perform a power on reset everthing is fine and the Readout-protection is set. What can I do to have FLASH_OB_Launch() working properly? Thanks a lot Andy2015-03-07 04:14 AM
You don't have NRST driven/tied high, right?
It's not clear how the buzzer gets enabled/disable, not evident from the code presented. If the processor tries to reset, it's probably going to do that before an interrupt.[DEAD LINK /public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/flash%20readback%20protection&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=705]https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=%2Fpublic%2FSTe2ecommunities%2Fmcu%2FLists%2Fcortex_mx_stm32%2Fflash%20readback%20protection&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5B¤tviews=7052015-03-07 08:12 AM
Hello Clive,
thanks for your answer! Don´t worry about the Buzzer, it was just a help to see where it hangs. Please assume the 2 Buzzer code lines as to be deleted. NRST is not tight high. Why is NRST important? Meanwhile I found out: Assume this situation to start: First the chip has no read protection. I download the firmware which enables read protection. I do this via JTAG, but make no reset via JTAG. I power down the unit and the make a power on reset. Everything works fine, no hang in FLASH_OB_Launch()!! ---------------- But the actual application should be: Chip has no read protection. Firmware that enables read protection is downloaded via USB to Ram. Thereafter the software is copied to flash. Thereafter a soft reset is performed. The new firmware is correctly started. It does a lot of initialisation job. Finally it comes to the point where programming the option bytes. In this situation it does NOT leave FLASH_OB_Launch() maybe because the flash does not leave the busy state. It seems to be an actual power on reset is necessary to solve the problem. But I do not understand why. Thanks a lot Andy2015-03-07 10:35 AM
Dear Clive,
I have to correct myself: The NRST Pin is driven activly high by the reset circuit! Hope this info can help you Andy2015-03-10 07:49 AM
Hello Clive,
I studied the source code of FLASH_OB_Launch(), I cannot find the point where it triggers a reset. Why does programming the option bytes involve a reset? Why you asked me whether my NRST Pin is tied high by external PushPull Device? I would be very happy about your reply to solve this issue. Thanks a lot Andy2015-03-10 08:29 AM
The Reset pin is bidirectional in ARM designs, if you drive it high the chip can't reset, or won't reset properly. The internal reset functionality won't work. You need to drive it low Open-Drain fashion, with a pull-up, say 10-100K
The option bytes are stored in FLASH, they are loaded into internal registers at reset, and only at reset. The signals from these registers are feed to other circuit elements, as they can't connect directly to the FLASH array.2015-03-10 09:39 AM
Hello Clive,
thanks for your soon reply. First I have to conclude that I was lucky so far the chip works at all with my NRST-Pin connected to PushPull device. Second the reason why FLASH_OB_Launch() hangs is my hardware fault not software fault. Because the chip cannot alter the NRST-Pin, the option bytes are not updated from their flash location --> FLASH_OB_Launch() doesn´t finish..... Thank for your clear explanation Andy