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:
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?
I tried with 2.18.0, but get the same behaviour when downloading a working binary: "Warning: The core is locked up" and an immediate HardFault if I download the binary via CubeIDE..
It seems the "Register" View in CubeProgrammer GUI was completely overhauled, but still, in the bottom right corner I can see "CPU: LOCKUP".