STM32 locked

[yohann]

Posted on February 13, 2014 at 08:48

Hello,

I use a STM32F405 in a design. I have a test softaware for the board to ttest GPIOs, CAN,...) It was working well, but suddenly nothning work at all (also functions that was working before). I try to reflash my program, but the flash memory seems to be locked. Can the CPU be locked (protected)? How can I unlock my STM32 and recover full operational working mode?

[chen]

Posted on February 13, 2014 at 10:08

Hi

Option Byte can set Read lockout and Write protect Flash sectors. Use the ST-Link Utility. There is a facility to change the option bytes in the util. We have found that changing the function of the SWDIO and SWDCLK pins with a ST-Link attached can cause option byte corruption and wipe the Flash. You may also want to set the BrownOut level to 2.7V (level2)

[troy1818]

Posted on February 13, 2014 at 10:22

Hi Goyer,

Is the sw you are using to flash your stm explicitly telling you that the flash is locked? If not, what exactly is the error message?There was another guy that had similar problem:https://my.st.com/public/STe2ecommunities/mcu/Lists/cortex_mx_stm32/Flat.aspx?RootFolder=https%3a%2f%2fmy%2est%2ecom%2fpublic%2fSTe2ecommunities%2fmcu%2fLists%2fcortex_mx_stm32%2fFlash%20Programming%20Locked%20Out&FolderCTID=0x01200200770978C69A1141439FE559EB459D7580009C4E14902C3CDE46A77F0FFD06506F5...Conclusion:''

Thanks for your help.  I was finally able to get the device unlocked again.  I was able to reset the RDP bytes in OPTCR through a GDB session.  Whew...''

Regards,/rygelxvi

[frankmeyer9]

Posted on February 13, 2014 at 11:00

Another possibility, assuming your hardware is ok, is a core lockout.

This happens, for instance, if the hardfault handler itself generates a hardfault.In this case, try getting you board into bootloader mode, and mass erase it. And your fault handling might need review, than.

[Tesla DeLorean]

Posted on February 13, 2014 at 13:23

Or that you simply can't access the core for mundane reasons like you reprogrammed the JTAG/SWD pins, or placed the core in a low power mode. Examine what you do early on in your code execution.

As fm suggested try the System Loader mode, set BOOT0 high and reset, observed if you can access the core then.

[yohann]

Posted on February 17, 2014 at 17:05

Thanks for your support.

I was not in offices end of last week and I see many responces. First of all you shall know that I'm testing a board (prototype) developped by a supplyer. For that I check some points on the Hardware and I may have make some short circuit on the board. The board already worked (I can flash it, and the soft was running well). We are using Openocd (0.7.0) with a OLIMEX gateway.

We got errors by flashing a software.

(sory I do not find any solution tu put image of screen shot on this forum) command:

“C:\Software\openocd-0.7.0\bin-x64\openocd-x64-0.7.0.exe -d0 -f C:\Software\openocd-0.7.0\scripts\interface\olimex-arm-usb-ocd-h.cfg -f C:\Software\openocd-0.7.0\scripts\target\stm32f4x.cfg -c init -c targets -c ''halt'' -c ''flash erase_sector 0 0 11'' -c ''flash write_image c:\\temp\\HAL_Test\\HAL_Test.hex'' -c ''verify_image c:\\temp\\HAL_Test\\HAL_Test.hex'' -c ''reset run'' -c shutdown�?

results:

• debug level: 0
• adapter speed: 1000 kHz
• Adapter nsrst delay: 100
• jtag ntrst delay: 100
• cortex m3 reset config sysresetreq

We got the followings errors:

• JTAG STICKY ERROR
• MEM_AP_CSW 0x23000051, MEM_AP_TAR 0x1FFF7A24
• stm32x device protected
• failed erasing sectors 0 to 11
• flash write alo aborded by target
• Error executing stm32x flash write algo
• FLash memory write protected
• flash write failed = 0000000010

error writing to flash at address 0x0800000000 at offset 0x00000000 in procedure flash

After that we try with the tool ''Putty'' (v0.62.0.0) advised by our supplyer.

The configuration is Host: localhost / port: 4444 / connection: telnet We use this command: “C:\Software\openocd-0.7.0\bin-x64\openocd-x64-0.7.0.exe -d0 -f C:\Software\openocd-0.7.0\scripts\interface\olimex-arm-usb-ocd-h.cfg -f C:\Software\openocd-0.7.0\scripts\target\stm32f4x.cfg�?That connect the tool to the board. Then we send the followings commands:

- stm32f2x mass_erase 0

- stm32f2x unlock 0

- resetBut the CPU is still lock at the end. Can someone can explain me what happend? Can I have any hop about unlocking this board? Or should I wait next prototype bench? Thanks.      

[Tesla DeLorean]

Posted on February 17, 2014 at 17:28

Try commercial JTAG/SWD solutions, open source is great if you can fix your own problems.

The ST-LINK tool as it's own Utilities which provide support for their chips. Consider if you can use a USART (USART1 or 3), or USB (DFUSE) to recognize and program your device. For the USART download a copy of the

http://www.st.com/web/en/catalog/tools/PF257525

, for USB

http://www.st.com/web/catalog/tools/FM147/CL1794/SC961/SS1533/PF257916