STM32H750IB crashing and cannot be connected to or halted with JTAG debugger

[TallMike]

I’m running into a ‘Heisenbug’ crash (just adding or moving a bit of general code between builds makes it either crash or work), and when it crashes, the STLINK-V3MINI can’t attach, or if already attached, it fails to halt the processor.

Any tips or advice about catching it in the act or theories as to the cause?

 

 

[AScha.3]

If your program is as good as your information about it, it's a pebkac problem.

 

- did you try a simple standard test program, like blinking LED? What then? 

- did you connect in CubeProgrammer in different modes: soft/hardware reset, under reset, hot plug, etc?

- did you setup in Cube the SWD pins for debug? And not reuse pins in program for anything else?

[TallMike]

The program is much better than the (admittedly sparse) information about it!   But seriously, for you to assume pebkac for no reason is a bad look on you.  

What I was hoping for was information about the kinds of crashes / wedges that would prevent the JTAG from even being able to connect or halt the processor, independently on how it got there. 

More details:  When it’s not the in the heisenbug ‘state’ (and even when it is and hasn’t yet crashed), the openOCD and gdb work fine (can break, read and write memory, etc).  Then if e.g. I add or move something to try to narrow down the crash (but don’t actually change anything functional, then it either will or won’t crash (e.g. moving things around in memory is saving it from apparently some mystery overwrite or incorrect read).  It’s using DMA for one of the serial ports, and using the SAI for stereo audio in/out.  It’s on an ElectroSmith Daisy board, using a lot of their code plus some customizations.  

 

[lobna]

Hello ​@TallMike 

Do you use cache memory in your application?
The problem could be a speculative access from the Cortex-M7. It can cause a hang if it touches an invalid or improperly managed memory region, which can trigger a fault or a lockup state.
If you use the MPU, please make sure all unused memory regions are marked as XN.

 

BR

Lobna

[lobna]

You can use Speculative access on Cortex®-M7 and Cortex®-M85 based STM32: A practical guide | Community

[TallMike]

Hi, ​@lobna , thanks for the helpful and useful suggestions!  Indeed we were using caching, on a QSPI flash device.  It was apparently wedging the D2 bus and keeping it from completing the instruction.  We’ve disabled caching on that region, which seems to have fixed it!

Also, for anyone encountering an ‘unhaltable’ processor, you can get an approximate location from the DWT_PCSR — the Program Counter Sample Register — at 0xE000101C (DWT base 0xE0001000 + 0x1C). Reading it over
  SWD returns a recent PC sample from the running (or wedged) core without halting it.