Check your exact target MCU, and the datasheet.
I had a similiar effect when I accidentally tried to reconfigure the SWD pins of the target. The debugger/JLink "screwed up" immediately.

Now this was a pure assumption on my side.

My next step would be to step into the "offending" code on instruction level, and watch relevant port and RCC registers.
The latter one's are where the power to the individual peripherals are enabled.
In my case, I had accidentally written a GPIO config to port A instead B, overwriting the SWD pin config.

I have quite a distaste for Cube/HAL, to be frank.
But if I remember correctly, most of the peripheral init routines start with a DeInit call.
I would check they don't do anything out of the ordinary.

Another failure option is the power supply.
I remember having had such a debug fail on a board with a LCD display attached.
As soon as I initialised the display the power supply folded, and the debug connection was lost.
It worked fine with an external supply.

Anyway, I would continue debugging on instruction level, and check if the point of failure is consistent.
And if so, which addresses it involves.

Perhaps you have noticed the recent posts about mistakes in the F3xx support packages.
For me they caused a hardfault on the first stack access, because of non-existing memory.
Other support packages (seems you have an L0xx device) could be erranous, too.

Hello,

Thank you for your inquiry.
Release mode usually includes some kind of code optimization. Please note that with code optimization active debugging becomes oftentimes impossible and the code referencing of our debugger is a complete guessing game. So your Breakpoint that you set on some function could be in reality somewhere completely else in your optimized application.

So first for debugging we recommend to use the debug build with code optimization disabled.
Does your application work now as expected?
If not, how does it behave now? Do you have any low power/sleep modes active that might block the debug interface temporarily e.g. WFE/WFI instructions?
Oftentimes ST HAL has sleep active on default. We recommend to disable/avoid them for debugging.

Once you have a working debug build try building the release build and flash it to your target. Does your application work now standalone as expected? If yes everything is fine.

Also we always recommend to use the latest Embedded Studio version where possible to avoid running into bugs that might already been fixed by newer versions of our toolchain and IDE.

Best regards,
Nino

As Nino posted, sleep modes and wake-up are a known source of trouble for debugging.
Though this seems not to apply in your case.

I am not too well versed in assembler code, but this code is supposed to load a 32-bit word into a core register.
I can't really imagine how it could fail. Or does it happen in following instructions ?

Leaving aside the quality of the HAL code/library in general, two things come to my mind.
First, I hope the UART peripheral is properly initialized. Some MCUs hardfault when trying to access peripherals which have the clock not enabled (RCC). Which includes the GPIO pins they are routed to (GPIOx).
Second, some incorrectly configured DMA might cause your problems. Which is again pure assumption.
You could try to remove/disable other peripherals, and run the code with the UART enabled.

By the way, when I wrote about "destroying" the debug connection by reconfiguring the debug pins, this looks different.
As soon as I stepped over the erraneous pin init, the debugger displayed a message box "connection lost", and that was it.
The score register values "0xdeadbeef" and "0xaaaaaaaa" for variable hown in your case suggest that something is messing with the debug peripheral.
The first one ("0xdeadbeef") looks suspiciously like a stack/memory initialisation value to check for runtime overflows.

I never devoted much time to study debugger internals or Cortex ETM/ITM peripherals ...