STM32L152 keeps external resetting. Flashing is succesfull, but after that it keeps resetting over and over again. Does anyone why?

[DHova.1]

Here is the report:

Open On-Chip Debugger 0.11.0-rc2+dev-00037-g4c4dbd9 (2021-02-09-13:39)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.org/doc/doxygen/bugs.html

Info : Listening on port 6666 for tcl connections

Info : Listening on port 4444 for telnet connections

Info : STLINK V2J37S0 (API v2) VID:PID 0483:3748

Info : Target voltage: 2.903249

Info : Unable to match requested speed 8000 kHz, using 4000 kHz

Info : Unable to match requested speed 8000 kHz, using 4000 kHz

Info : clock speed 4000 kHz

Info : stlink_dap_op_connect(connect)

Info : SWD DPIDR 0x2ba01477

Info : STM32L152RCTx.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : starting gdb server for STM32L152RCTx.cpu on 3333

Info : Listening on port 3333 for gdb connections

Info : stlink_dap_op_connect(reconnect)

Info : SWD DPIDR 0x2ba01477

Info : STM32L152RCTx.cpu: external reset detected

Info : accepting 'gdb' connection on tcp/3333

Info : Device: STM32L1xx (Cat.3 - Medium+ Density)

Info : STM32L flash size is 256kb, base address is 0x8000000

Warn : GDB connection 1 on target STM32L152RCTx.cpu not halted

undefined debug reason 8 - target needs reset

Info : stlink_dap_op_connect(reconnect)

Info : SWD DPIDR 0x2ba01477

Info : STM32L152RCTx.cpu: external reset detected

Info : stlink_dap_op_connect(reconnect)

Info : SWD DPIDR 0x2ba01477

Info : STM32L152RCTx.cpu: external reset detected

Info : stlink_dap_op_connect(reconnect)

Info : SWD DPIDR 0x2ba01477

Info : STM32L152RCTx.cpu: external reset detected

Info : stlink_dap_op_connect(reconnect)

Info : SWD DPIDR 0x2ba01477

Info : STM32L152RCTx.cpu: external reset detected

Info : stlink_dap_op_connect(reconnect)

Info : SWD DPIDR 0x2ba01477

Info : STM32L152RCTx.cpu: external reset detected

Info : stlink_dap_op_connect(reconnect)

Info : SWD DPIDR 0x2ba01477

Info : STM32L152RCTx.cpu: external reset detected

Info : stlink_dap_op_connect(reconnect)

Info : SWD DPIDR 0x2ba01477

Info : STM32L152RCTx.cpu: external reset detected

Info : stlink_dap_op_connect(reconnect)

Info : SWD DPIDR 0x2ba01477

Info : STM32L152RCTx.cpu: external reset detected

Info : accepting 'gdb' connection on tcp/3333

Warn : GDB connection 2 on target STM32L152RCTx.cpu not halted

undefined debug reason 8 - target needs reset

undefined debug reason 8 - target needs reset

shutdown command invoked

Info : dropped 'gdb' connection

shutdown command invoked

[Tesla DeLorean]

You have something else attached to the NRST line?

There is a Watchdog executing in your code, or prior code.

There is a POR circuit detecting low voltage. Check VDDA

[DHova.1]

You have something else attached to the NRST line? Nothing Attached, Stable 2,85V

There is a Watchdog executing in your code, or prior code. No watchdog executed

There is a POR circuit detecting low voltage. Check VDDA. Stable 2.95V

When I copy from:

https://github.com/STMicroelectronics/STM32CubeL1/blob/master/Projects/32L152CDISCOVERY/Examples/GPIO/GPIO_IOToggle/Src/main.c

everything works just fine, but when I use the STM32Cube device tool configurator to create code, then it doesn't work.

[TCC]

I have run into a similar problem using the same micro.  Were you able to resolve the problem? What was the fix?

[Tesla DeLorean]

Custom board? Some code works fine, but others cyclically reset?

Check clocking expectations, input clock, HSE_VALUE, PLL settings.

Perhaps comment out code switching to HSE/PLL and let continue with MSI/HSI default. 

[TCC]

I am using a custom board.  Nothing else is on the NRST line.  NRST is pulled to Vcc through a 10k resistor.  The program will execute up to 500 lines of code before getting an external reset.  Using HSI, not HSE.  Configuration code was generated using STM32CubeIDE.  I have stripped the application code down to just a loop and counter.

[Tesla DeLorean]

Using a WatchDog ?

Simple LED / GPIO toggle in main(), basically just initialize the pin, drive high / low, and scope pin does that crash? Avoid calling HAL_Init(), SystemClock_Config(), etc. Keep it simple.

Supply droops? POR/BOR settings in Option Bytes? NRST pulses lows? scope

Provide a schematic of salient connections to STM32. Going to be hard to diagnose without some detail.

VDDA/VSSA connected to supplies

[TCC]

I did as you suggested and simplified my code.  With calls to HAL_Init and SystemClock_Config() removed and the software simply toggling an output, I do not experience any external interrupts.  When I call HAL_Init or SystemClock_Config() an external interrupt occurs within a few microseconds.  There are no pulses on NRST.  I can provide details on the hardware, but this seems to point to a problem with HAL_Init.  I will try to modify my production code to eliminate those calls. 

[Tesla DeLorean]

The trick would be to understand why these precipitate failure, and why interrupts or whatever aren't handled.

[Piranha]

And now the "external reset" turned into an "external interrupt", which is a totally different thing. If there are no pulses on NRST, then there is no reset either. Most likely what is actually happening here is just an infinite loop and/or hard fault. And you still didn't answer about a watchdog...