STM32L4 in Stop2 mode (Debug vs Release)

[dtarrago]

Good morning,

I have an application based on the STM32L475 device that is running in many devices since many years ago. We have observed that, sometimes, some of the devices are resetted --> Here you have the main specs of my device:

- Device is working in Stop2 mode

- It's is waking up every 31.25ms because of RTC interrupt, in order to do all the tasks. And then it goes back to stop2 mode

- Device has a watchdog implemented (1.5")

We have observed that some devices are automatically reseted sometimes: some devices are reseted many times par day, some devices are reseted a few times par day, or some devices are never reseted.

In order to allow us look for this reset reason, we have set device in debug mode, but surprisingly, in debug mode device is never stopped or reseted. So, we can not find the reset reason.

The main differences between debug and release mode are:

- Debug mode:

                   - Watchdog is obviously not working

                   - HAL_DBGMCU_EnableDBGStopMode function is called once before entering into main loop

All the other code is the same. And in the main loop we have this:

int main(void)
{
/* Clear reset flags in any cases */
  __HAL_RCC_CLEAR_RESET_FLAGS();

  /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
  HAL_Init();

//Variables initialization
Var_Par_Init();


__HAL_RCC_WAKEUPSTOP_CLK_CONFIG(RCC_STOP_WAKEUPCLOCK_MSI);	

//Only in debug mode
#ifdef EN_DEBUG 
HAL_DBGMCU_EnableDBGStopMode();
#endif 

 while (1)
  { 
	
	Tasks();	

	if(Equip_STOP_Mode()==SI) //No task is running so we can go to stop2 mode
	{							
				
		//Enter into Stop2 mode
		HAL_PWREx_EnterSTOP2Mode(PWR_STOPENTRY_WFI);						
		//When exiting Stop2 mode, clock is re-setup
		SYSCLKConfig_STOP();				
							
	}
					
		
}
}

So, which is the difference between Debug and Release mode in this case? Any idea how to find the reason of these resets?

[TDK]

If the watchdog is resetting the chip, it's probably not being reloaded in time. Check that assumption.

Toggle a pin every time you pet the watchdog, Verify that pin and the NRST line to verify if you're doing this in time. Probably you will find a delay of 1.5s before NRST drops low due to the watchdog.

Are there other reasons to suspect your 31.25ms wakeup isn't occurring? Perhaps you have a race condition occurring here, or some other code error in the setup. Consider disabling the watchdog during debugging and implementing diagnostics to verify the 31.25ms wakeup always occurs.

[dtarrago]

31.25ms is always ocurring as this base time is used to manage all the functionality in what regards synchronization, and synchronization is always perfect.

Furthermore, the whatdog is always refreshed using HAL_IWDG_Refresh, and this is done in the 'Tasks' function, that is contantly called once the device has woke up (every 31.25ms).

In order to have more information: besides the differences in code I have detailed, which are other differences between Release and Debug mode?

[TDK]

Release has higher optimization settings. It results in faster code which sometimes exposes bugs that are masked during Debug mode.

[dtarrago]

So, which steps to you recommend to follow?

I have started by building release version without optimization (Level 0)

[TDK]

> So, which steps to you recommend to follow?

To build? Either Debug or Release should work, provided there are no bugs. If you don't need speed, it's fine to stick with Debug in order to avoid debugging, provided you're okay not knowing what is causing your issues.

If you're asking what steps I recommend to diagnose, I suggested some things in my first reply. The watchdog is not prone to misbehaving, so recheck your assumptions that you are resetting it appropriately, also check RCC->CSR flags on startup to confirm it was a watchdog reset and not something else.

Intermittent bugs are hard to spot, but "many times per day" should be doable. You just need to improve diagnostics being sent out from the chip.

[dtarrago]

I built my app in O0 mode (no optimization), as up to know I was working in O1 mode.

Now, after a few days with a few equipment working with this new software version (with no optimitzation), no resets have been reported in any equipment. So, problem seems to be related with optimization: as we have no problem with space, we will go ahead with this option.

The only problem raisedd with no-optimization is that a verification problem appears when flashing the MCU with the flashing tools: this seems to be due to the fact that hex file size is not multiple of 8 bytes --> If some code is added to allow the hex file size to be multiple of 8, the error dissapear. Do you know an other way to solve this?

[TDK]

The easiest way is to ensure the binary is a multiple of 8 which can be done modifying the linker script so the end is padded/aligned to the word size. Different tools behave differently when flashing only a portion of a flash word--some fill with 0x00 and some with 0xFF.