Can't get my STM32L496AG13 to run

[DCato.1]

I have a stm32L496AG13 on a custom Board

Running code that was tested on a development board, in debug mode, the code crashed at random places during HAL init

I worte a new program using STEMCubeIDE version 1.12.0 and put in a simple program:

 while (counter1 <= 3)

 {

   counter1++;

   }

Everything else is default as the IDE built it. 

I can step through main and then it goes to LoopForever() in startup_stm32l496agix.s

But when I try to run full speed it crashes.

I note the reset pin NRST# is asserted for about 30 us when it crashes and I think It's being asserted by the stm32L496AG13.

Looking at the CSR register, I see that it's 1C00 0600 before the crash and 1C00 0610 after.

I have a couple of questions about this:

1) The manual for the MCU says the reset value for this CSR register should be 0C00 0600, but it's not, indicating a software reset (1C000600).

But this register is like this from the very beginning and if I step through main and then let it run it stays that way (1C000600) and the chip never resets 

2) Why would the reset value indicate Brownout and Pin resets(0C00 0600)? and why would they stay set?

3) Why is the LSI only becoming ready after the chip is reset? (1C00 0610) 

I'm reading the CSR register by looking at the FSR tab and toggling live update.

I'm using the SWD debugger at 140 kHz with SWW disabled and logging to file, using an STLink V3 set with a ribbon cable interface

I'm just trying to find out why the board is resetting.

[Tesla DeLorean]

>>I'm just trying to find out why the board is resetting.

Power issues causing a POR to trigger

Watchdog running

Something calling NVIC_SystemReset()

Some pin level shorting, or connectivity

>>I can step through main and then it goes to LoopForever() in startup_stm32l496agix.s

Returns inexplicably from main() ?

Getting an interrupt you don't have a relate IRQHandler set up for? Naming issue with the IRQHandlers you do have (.CPP / C++ Name Mangling)

[DCato.1]

It doesn't return inexplicably from main. When main is done it just goes to do forever.

The only interrupt handlers there are have been auto-generated.

The 3.3 V used for VDD is rock solid.

Neither the SWW or the IWDG watchdogs are enabled

I set a breakpoint at NVIC_SystemReset( ) and it never hit.

I'm looking at system level connectivity

This behavior is identical on two PWAs

The debugger usually does this when I step through:

GDB session, device event: 3

GDB session, device event: 3

GDB session, device event: 1

GDB session, device event: 1

GDB session, device event: 0

GDB session, device event: 0

It does this when it fails:

GDB session, device event: 3

GDB session, device event: 3

GDB session, device event: 1

GDB session, device event: 1

ST-LINK device status: RESET_MODE

ST-LINK device status: RUN_MODE

I can't find what these device events are.

Looking at the power registers, they don't seem to change except the low power oscillator becomes ready.

Are there any other registers I can look at that would give me a clue?

[Tesla DeLorean]

LoopForever isn't exported, the only way there is to leave main(), or for the stack frame to get corrupted.

The code working on other boards, and not the custom one, points to powering issues on the latter.

Other unhelpful while() loops would be those in Error_Handler() or HardFault_Handler(), best to instrument those to determine entry reasons.

In HAL_Init() perhaps look at what's going on in there, where SysTick or TIMx are being used for a time-base, and related Handlers are called and structures/instances are fully initialized at the point of first use.

Default_Handler is a loop where unbound IRQ Handlers will dump into.

Simplify the code until it doesn't reset.

Get a USART working early to inform on progress and flow.

Critically review the board design and chip connectivity.

Check for secondary devices driving NRST, anything driving HIGH

[DCato.1]

I was only getting to loop forever if I stepped out of main().

The other board was a development board that worked, but had different memory and clock configuration and used USB direct debugging and was a different chip. The custom board with the original code developed on the dev board failed at random places during the hardware setup. I had the IDE develop a simple piece of code for the new board that only counts to three in the main loop, nothing else. The new program fails more consistently at the end of the while loop, where the index reaches it's terminal count. Error_ Handler(), Fault_Handler(), and Default_Handler() are never called. I'll look at HAL_Init(), but I think most of what that's doing is needed for the chip to function. I wonder if somehow something didn't get set up correctly by the IDE, or if there are any other registers, I can look at to figure out why the chip is resetting. We will continue to look critically at the board design, but with the new code most of the peripherals are disabled. I will try to pare down the code more if I can, but it's already minimal.

[Tesla DeLorean]

Double check that HSE_VALUE reflect new board configuration. See stm32l4xx_hal_conf.h

Double check PLL gearing and that part isn't over clocked.

Check internal clocks via PA8 / MCO pin

Try just running from MSI clock (the one it starts with) ignoring HSE / PLL until basic operation confirmed.

Perhaps initialize a pin in Reset_Handler, and toggle there.

Check Option Bytes for Watchdog settings

With little happening on-chip, points at board/electrical issue.

[DCato.1]

HSE Value Checks. Tried using the MSI clock, no help. PLL gearing not overclocked, It's 16 MHz Just like MSI RC. I can't use the MSO Pin because it wasn't brought out and I'm using a BGA. One thing has me confused:

The manual states:

"If the “Hardware watchdog�? feature is enabled through the device option bits, the watchdog

is automatically enabled at power-on, and generates a reset unless the IWDG key register

(IWDG_KR) is written by the software before the counter reaches end of count or if the

downcounter is reloaded inside the window."

I'm pretty sure I'm not writing the Key register, but I can't figure where the hardware watchdog option bit is. Looking at the *.ioc file, neither WWDG or IWDG are activated.

Thanks for your help. I will be out for about a week but will come back to this.

[Tesla DeLorean]

I'd expect you can adjust option settings via one of the tabs in STM32 Cube Programmer