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. 

 

[TCC]

It was late and I wrote external interrupt, not external reset.  That was my mistake.  I have slimmed my code down to a loop that toggles an output.   There is no watchdog.  As suggested I did not call HAL_Init() or SystemClock_Config() and I saw no external resets.  When I said there were no pulses, I meant that NSRT does not go low at the time of the external reset.  If I call Hal_Init(), I will get an external reset.  So it appears that there is something in that module which is causing the reset.  The documentation says that the external reset bit is set only by NRST going low.  But I have verified that is not happening.  Do you know what other conditions can cause that bit to be set?

[Tesla DeLorean]

If the signal is not going low, it suggests it's something else. If triggered it should be clamped low, at least briefly.

The bit might be sticky from the initial power-up reset. You're implying that it keeps reentering the Reset_Handler. Or some cyclic behaviour.

Not familiar with your circuit or software.

Suspect power issues, something with SCB->VTOR, or some external GPIO connectivity.

Bisect the code, determine what specifically in HAL_Init(), etc is triggering the cyclic behaviour.

[TCC]

Right now I am just going into an infinite loop when I get a reset.  I've tracked the problem down to a statement in HAL_InitTick().  It appears to be the HAL_SYSTICK_Config call in the section of code below.  If I replace that call with a true condition, then I do not get any external resets.  I've also included my schematic and main.c from the program I am using to work this problem.  Your help is much appreciated.

 

if (HAL_SYSTICK_Config(SystemCoreClock / (1000U / uwTickFreq)) == 0U)

{

/* Configure the SysTick IRQ priority */

if (TickPriority < (1UL << __NVIC_PRIO_BITS))

{

HAL_NVIC_SetPriority(SysTick_IRQn, TickPriority, 0U);

uwTickPrio = TickPriority;

}

else

{

status = HAL_ERROR;

}

 

[TCC]

That seems to have taken care of the problem.

[Tesla DeLorean]

Which?

[TCC]

Pulling BOOT0 low.  Thanks for all your help.