Reasons for deadlock in H7 series

[rokostrup]

Hi all,

 

I've recently begun playing around with Zephyr and made blinky for a custom board with a STM32H755.

To test it, I made a complete chip erase and then I flashed the application to the M7 (i.e., its flash area). I can then attach to a debugger immediately after this (without power cycling) and step around in the code, but as soon as I do a power cycle the board is completely dead - I cannot attach my debugger to the target at all.

 

I read in other posts that this could be caused by a bad SMPS / LDO choice.

However, this seems to be chosen correctly by the zephyr soc_m7 file (choosing SMPS).

I suspect that it has to do with the M4 blocking or somehow acting bad - even though no code is loaded into it, it is still booting (i.e., CM4 has its option byte (BCM4) set).

 

So my question is: what are all the possible reasons for not being able to connect the STM32H755 with a debugger (given that it is powered up), except for the bad choice of regulator?

 

P.S.

Let me know if I should upload the code I used.

[Danish1]

If you reassign/reprogram the pins used for SWD/JTAG (or disable the clock to their port) then the debugger can't connect. Unless you explicitly "connect under reset" (not sure what the stm32cubeide calls this).

It's possible that once the debugger has connected such reassignment might be prevented.

[rokostrup]

But SWD / JTAG are automatically assigned to their default pins (and default is them being active) if I don't touch them, right?

[Tesla DeLorean]

Did you write the code or was it auto-generated?

The BOOT0 pin gets to decide what code runs out of a power cycle. Check if you can access with BOOT0 =HIGH

Try connect uder reset if NRST was wired to the debug interface.

Add some dwell time in Reset_Handler. 

Spinning in a WFI loop can power down the debug interface in some situations.