cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H563 Warning: The Core is locked up

beartronics
Associate II

Hi,

I'm currently developing a custom application which provisions and regresses an STM32H563, using the NUCLEO-H563ZI board for development.

The CubeProgrammer CLI commands I'm executing are based on the bash scripts generated by CubeMX. Since I started playing around with those, somewhere the MCU got into a state which I can't get it out of.
Starting a Debug Session with a fully working Binary (tested on my 2nd Nucleo Board) results in an immediate HardFault. Breakpoint at Reset_Handler not even triggered. BFARValid == 1, BFAR = 0x2009fff0, contents of 0x2009fff0 unreadable.

In CubeProgrammer GUI, I can Halt the CPU immediately after resetting, showing a PC of 0x80034E0 (reset handler address), and when stepping one more time, PC = 0xEFFFFFFE.

When Downloading a Binary through the GUI, I get a warning "The Core is locked up". Full Connect&Download Output:

Spoiler
09:15:21 : Disconnected from device.
09:15:22 : UR connection mode is defined with the HWrst reset mode
09:15:22 : ST-LINK SN : 0032002B3132511238363431
09:15:22 : ST-LINK FW : V3J15M7
09:15:22 : Board : NUCLEO-H563ZI
09:15:22 : Voltage : 3.25V
09:15:22 : Warning: Connection to AP 0 requested and failed, Connection established with AP 1
09:15:22 : SWD freq : 8000 KHz
09:15:22 : Connect mode: Hot Plug
09:15:22 : Reset mode : Software reset
09:15:22 : Device ID : 0x484
09:15:22 : Revision ID : --
09:15:22 : Debug in Low Power mode enabled.
09:15:22 : SFSP Version: v2.5.0
09:15:22 : UPLOADING OPTION BYTES DATA ...
09:15:22 : Bank : 0x00
09:15:22 : Address : 0x40022050
09:15:22 : Size : 112 Bytes
09:15:22 : Bank : 0x01
09:15:22 : Address : 0x40022070
09:15:22 : Size : 16 Bytes
09:15:22 : Bank : 0x02
09:15:22 : Address : 0x40022080
09:15:22 : Size : 16 Bytes
09:15:22 : Bank : 0x03
09:15:22 : Address : 0x400220e0
09:15:22 : Size : 16 Bytes
09:15:22 : Bank : 0x04
09:15:22 : Address : 0x400221e0
09:15:22 : Size : 16 Bytes
09:15:22 : Bank : 0x05
09:15:22 : Address : 0x40022090
09:15:22 : Size : 8 Bytes
09:15:22 : Bank : 0x06
09:15:22 : Address : 0x400220f0
09:15:22 : Size : 8 Bytes
09:15:22 : Bank : 0x07
09:15:22 : Address : 0x400221f0
09:15:22 : Size : 8 Bytes
09:15:22 : Bank : 0x08
09:15:22 : Address : 0x400220f8
09:15:22 : Size : 8 Bytes
09:15:22 : Bank : 0x09
09:15:22 : Address : 0x400221f8
09:15:22 : Size : 8 Bytes
09:15:22 : UPLOADING ...
09:15:22 : Size : 1024 Bytes
09:15:22 : Address : 0x8000000
09:15:22 : Read progress:
09:15:22 : Data read successfully
09:15:22 : Time elapsed during the read operation is: 00:00:00.008
09:15:32 : Memory Programming ...
09:15:32 : Opening and parsing file: stm32h5-bootloader.bin
09:15:32 : File : stm32h5-bootloader.bin
09:15:32 : Size : 338.34 KB
09:15:32 : Address : 0x08000000
09:15:32 : Erasing memory corresponding to segment 0:
09:15:32 : Erasing internal memory sectors [0 42]
09:15:32 : Download in Progress:
09:15:33 : File download complete
09:15:33 : Time elapsed during download operation: 00:00:01.212
09:15:33 : Verifying ...
09:15:33 : Read progress:
09:15:34 : Download verified successfully
09:15:34 : RUNNING Program ...
09:15:34 : Address: : 0x08000000
09:15:34 : Warning: The core is locked up
09:15:34 : Start operation achieved successfully

The CLI Commands I used in my custom application are those (roughly from regression.sh):

STM32_Programmer_CLI -c port=SWD speed=fast ap=1 debugauth=3
STM32_Programmer_CLI -c port=SWD speed=fast ap=1 -hardRst -ob TZEN=0xC3
STM32_Programmer_CLI -c port=SWD speed=fast ap=1 -sdp ./DA_ConfigWithPassword.obk
STM32_Programmer_CLI -c port=SWD speed=fast ap=1 debugauth=1 per=a pwd=./password.bin

Which, in hindsight, I should have thought more thoroughly about, because they make little sense in my application (no TZ). I believe one of those commands triggered my issue. Unfortunately I cannot say for sure, because it took a while to realize the MCU was not running properly any more...

I tried resetting all the option bytes to their default values, but still experience the Core Lockup.
I also tried Provisioning, Closing and Debug-Authenticating the Device multiple times using the GUI, to no effect.
Other Posts with other STM32 Series MCUs (F, L, ...) describe the solution to move out of RDP, but I think this option byte was removed in the H(5) Series...

Is there a way to get out of this problem or did I brick my MCU completely?

Thanks in advance and best regards,
Stefan

0 REPLIES 0