STM32H503 core enters Lockup state when bootloader "Go" command is used

[Torin]

My board uses the STM32H503KBU6 and I'm using the built-in bootloader with the FDCAN interface, as documented in AN5405.

My firmware application is located at 0x08000000, and I am attempting to use the "Go" command to jump to it while the bootloader is running. This is required for our manufacturing and provisioning processes.

As specified in AN5405, I send a frame with ID 0x021, with DLC 4 and the data bytes containing the address, MSB first. The bootloader sends me two ACK frames as expected.

TX B -  021  [04]  08 00 00 00
RX B -  021  [01]  79
RX B -  021  [01]  79

At this point, all activity stops. The bootloader is not running, and neither is my application.

When I attach a debugger, the debug register tells me the chip is in the Lockup state. This is defined in the Armv8-M architecture reference manual as follows:

Lockup is a PE state where the PE stops executing instructions in response to an error for which escalation to an appropriate HardFault handler is not possible because of the current execution priority. An example is a synchronous exception that escalates to a Secure HardFault, but cannot escalate to a Secure HardFault because a Secure HardFault is already active.

The Armv8-M RM gives some examples of scenarios that can cause this state, but I am currently unable to determine which (if any) apply.

My application, for the purposes of testing this issue, is a barebones application generated by CubeMX; it does nothing particularly special. It has the standard init procedures, then blinks an LED in a loop. This application runs absolutely fine upon power-on reset, and pin/pad reset.

My current debugger setup just aborts when the Lockup state is detected - I am currently fixing this issue, then hopefully I can provide register dumps, backtraces, etc.

In the meantime, if anyone has any advice I would greatly appreciate it!

Adding some tags: H5, H503, STM32H503, STM32H503KB, CAN-FD 

[Torin]

Adding some debug attempt details.

I have an ST-Link attached to the board via SWD. I boot the board up while holding the BOOT0 pin HIGH, so that the bootloader is executed. I release the BOOT0 pin immediately.

I run the official ST-LINK GDB server with the following flags:

--swd --attach --persistent --apid 1 --verbose

The server starts with no issues:

STMicroelectronics ST-LINK GDB server. Version 7.7.0
Copyright (c) 2024, STMicroelectronics. All rights reserved.

Starting server with the following options:
Persistent Mode : Enabled
Logging Level : 31
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Enabled
SWD Debug : Enabled

COM frequency = 4000 kHz
Target connection mode: Attach
Reading ROM table for AP 1 @0xe00fefd0
Hardware watchpoint supported by the target
ST-LINK Firmware version : V2J43M28
Device ID: 0x474
PC: 0x0
ST-LINK device status: RUN_MODE
ST-LINK detects target voltage = 0.01 V
TrustZone: Active
ST-LINK device status: RUN_MODE
ST-LINK device initialization OK
Stm32Device, pollAndNotify running...
SwvSrv state change: 0 -> 1
Waiting for connection on port 61235...
Waiting for debugger connection...
Waiting for connection on port 61234...

I attach my GDB and continue execution:

(gdb) target extended-remote localhost:61234
Remote debugging using localhost:61234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x0bf8c698 in ?? ()
(gdb) cont
Continuing.

The server is happy:

GDB session thread running
GdbSessionManager, session started: 1
Try halt...
ST-LINK device status: HALT_MODE
GDB session, device event: 3
GDB session, device event: 1
ST-LINK device status: RUN_MODE 

I send the "Go" command via CAN-FD and receive the ACK frames. At the same time, the GDB server reports:

ST-LINK device status: LOCKUP
Enter STM32_SystemReset() function
GDB session, device event: 2
GDB session terminated: Device connection lost
GdbSessionManager, session terminated: 1
Stm32Device, pollAndNotify stopped
Cleanup session: 1
GDB session disposed: 1

GDB reports:

Remote connection closed

 So unfortunately, using the official tools, I'm not really any closer to debugging this!