STM32L562 and CubeIDE - CPU stalls branch instructions after taking it's first breakpoint

[Grizz]

Using the CubeIDE Rev 1.12.1, I have loaded an application and set a breakpoint in an STM32L562 uC. I am using a Segger J-Link Plus probe (does the same with ST Link V2) to debug.  I know something has happened to the CPU from a code stand-point as the ADC1 freezes once this quirk appears.  The other odd thing is that you cannot free run the CPU any longer nor can you step into any function calls.  The IDE shows that code is running and it's waiting for a breakpoint.  If you click the red square to stop the CPU, you notice that it does stop and respond, and indeed the CPU PC register is sitting at the instruction you tried to step into or step over.  The other thing you notice is the green LED on the Segger probe is blinking rapidly, but slowly enough you can see it turn on and off distinctly.

You can hit step over and successfully step over instructions up until the next branch instruction. Trying to step over it appears hung, but if you hit stop then step over, the stepping begins to work again until the next branch where the cycle repeats itself.

Any ideas on what I can inspect?  It seems odd to me that the only thing impacted is the "C" call functions.  Maybe this is because the SP (stack) is in play?

I'm also running in unprotected mode.  I didn't want to complicate matters with memory zones and protection until the application is completed and debugged.

[AScha.3]

sorry, but i dont understand, where is the problem and whats defective...

1. you have other cpu/boards , that work "normal" ?

2. this L562 is custom or nucleo.. or ?

3. was this L562 working "normal" before ? what happened then ?

4. which step in debug is now different than before ?

5. if make new, clean project for L562 , generate code, compile, debug: working ok ?

[Grizz]

Sorry, I've been busy on other projects... This is a custom board.  

When code is loaded and begins execution things work normally for about 250 mSec.  Then the CPU gets in some odd state where it no longer executes branch (call) instructions.  The CPU appears to stall on the instruction until you click the "suspend" or pause on the debug command bar. The CPU appears to complete execution and breaks and gives you debug control.  You can step over lines of code until you hit your next function call and that is when the processor appears stalled/held off.  Clicking suspend again gets you back to the debug window.

It seems that the memory write to the stack is being held off until I intervene with the debugger core. Could I have some clocks or memory write arbitration issues?

I'm using TIM1 to auto start ADC1 to take samples at 5.0 kHz and these are auto stored by the DMA into a ring buffer.  Curiously DMA cannot write to memory either when this odd CPU stall occurs.  I can inspect my ring buffer and see only 250 mSec worth of sample data there is ram.

So it seems I've done something to stop on chip ram writes by both the CPU core and the peripheral core.

I don't yet have trust zones enabled... wanted to keep things simple until this works.

Any debug ideas or thoughts on what could be blocking ram writes?

[Grizz]

Another bit of information... I have 2 debug LEDs and I was able to use those and the debugger to determine that my ram write/step over issues begin after the USB init call in my main().

MX_USB_Device_Init();

The code is IDE generated and uses a serial endpoint. The port talks to a debug app but at the time of init/setup the port is not connected to the host.