L476 locking up, hard to reconnect the debugger afterwards

[DiBosco]

I'm working on an project with an L476 using SWD. Main project is basically up and running, but I'm having problems with the bootloader.

The bootloader needs to be small as possible, so am avoiding the bloaty HAL and have set up the PLL. Seems OK in that the debug UART is kicking out exactly the right baud rate, but if I just run in a loop sending out 0x55 the unit locks up and loses the debugger connection.

The only way I can reconnect is by powering the unit up and hitting go on the debugger at exactly the right time. It can take scores of goes before I can reconnect. It keeps telling me that there is no part found.

So, some questions:

1. Should the debugger not hold the STM in reset and allow me to reconnect easily?
2. What could be causing this lockup? The RCC registers I *think* are OK, they look the same as in the main app other than I am only setting up on PLL as all I want is a couple of UARTs and to be able to self program flash.
3. I have setup the flash wait states to the max number, so I think that is fine too, is there anything there I might have forgotten?

Many thanks.

[Paul1]

Minimize, then add back features till see what is stopping it.

• Comment out all code, then uncomment block by block till see which stops it.

Possibilities:

• WDT - A watchdog enabled in MX isn't being kicked appropriately
• IRQ - An interrupt is enabled and occuring, but you aren't handling it, once it gets into the interrupt it exits, then immediately enters again.
• BUF - A buffer is filling, but isn't being emptied, code going into loop waiting for buf to empty
• more...

Paul

[DiBosco]

Hi Paul,

Thanks the the reply.

The code is already minimised, I'm doing nothing but initialise the PLL and UART then send out 0x55 over the UART in an infinite loop (with a short delay between sending the 0x55 out).

There are no interrupts enabled, the watchdog is not enabled. Even if there was an interrupt enabled, it wouldn't explain why the debugger gets locked out. Suggests to me that something non volatile is getting corrupted. I did try doing it by not initialising the PLL and that was OK, so it's surely something to do with that, but the frequency seems fine as the UART is at the right frequency. That's wht I wondered whether it might be a flash thing, but the latency seems right.

I also don't understand why connecting the debugger just doesn't allow me to reprogram because, as I asked abive, why doesn't the debugger hold the unit in reset and allow an easy reconnect. I've never come across this before in 15 ish years of using an STM32.

[Paul1]

LOL - You are the STM expert and I'm the beginner (30years MCUs, but relative beginner in STM).

I'll work on the principle of "no such thing as a stupid question", hoping my points inspire a thought that resolves this.

1. Did you try running your exact minimal project on the curiosity hardware?

If diff behavior that suggests a hardware difference.

Maybe a bad via? Good old meter work to probe out each pin-to-pin connection to verify connected.

Maybe a miss populated component (wrong value, orientation...)?

2. There is a debugger option in IDE for "Connect under reset"

Actually there are a mess of settings there that could wreak havoc.

Project >RightClick >DebugAs > DebugCfgs > Tab:Debugger > Reset Behaviour

Maybe the defaults have changed in IDE versions from what you were used to.

Paul

[Tesla DeLorean]

Perhaps some issue electrically? Solid grounds? No floating islands or disconnected nets? Double check netlists for net names for misnaming and connectivity, especially power nets.

Is NRST connected via your debugger interface?

Does HAL equivalent code fail similarly?

Debugger can have difficulty if low power modes used, pin latch-up or the chip simply non-functional.

Does complete power cycle of board, or turning off for a while alter behaviour/connectivity?

State of BOOT0 pin

[DiBosco]

I think we can rule out any sort of hardware issue. It's been working for two months just fine with the non-bootloader program. There's clearly something locking it up and it must be to do with the PLL and/or flash setup.

NRST *is* connected to the debugger, yes.

Paul, I checked the reset behaviour and at first I thought it must be because it was not selected as #connect under reset, but even changing to that does not help.

It seems easier to connect if I use the cube programmer. I can then erase the chip and all is well.