cancel
Showing results for 
Search instead for 
Did you mean: 

LSE config failed without battery

Matthias  Dübon
Associate II
Posted on January 04, 2018 at 10:10

Hello all,

we designed a STM32F429ZGT6 board. We're using a RTC and integrated a battery. We produced in a first batch of 50 of these boards and observed a strange behavior on 8 of these 50 boards. 

These boards are booting and behaving 'normal' when a battery is plugged in.

When we remove the battery the boards are not working any more. We tracked down the problem to the LSE clock configuration in the SystemClock_Config function If we don't configure the LSE clock the faulty boards are booting too.

We checked the external circuits and the components, everything seems fine. The problem is also not occuring when debugging the board with a debugger.

We checked the errata doc but did not find any hint. 

I also attached a screenshot of the schematic.

Any help would be very appreciated.

Matthias

#lse #battery-backup-rtc
1 ACCEPTED SOLUTION

Accepted Solutions
Posted on January 04, 2018 at 10:57

LSE is a low-power oscillator, basically a quite sensitive analog circuit. When powered from VDD, the bias conditions are different from when powered from battery.

'works when debugging' sounds like the LSE oscillator does start up but takes longer than when powered from battery; break into the loop waiting for LSERDY and single-stepping might then cover up this fact.

Try increasing the timeout.

I don' Cube so won't help with the details.

JW

View solution in original post

8 REPLIES 8
Posted on January 04, 2018 at 10:24

Show code (the offending part of it).

JW

Matthias  Dübon
Associate II
Posted on January 04, 2018 at 10:36

Hello,

the error happens here:

void SystemClock_Config(void)

{

RCC_OscInitTypeDef RCC_OscInitStruct;

RCC_ClkInitTypeDef RCC_ClkInitStruct;

RCC_PeriphCLKInitTypeDef PeriphClkInitStruct;

/**Configure the main internal regulator output voltage

*/

__HAL_RCC_PWR_CLK_ENABLE();

__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);

/**Initializes the CPU, AHB and APB busses clocks

*/

RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE|RCC_OSCILLATORTYPE_LSE;

RCC_OscInitStruct.HSEState = RCC_HSE_ON;

RCC_OscInitStruct.LSEState = RCC_LSE_ON;

RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;

RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;

RCC_OscInitStruct.PLL.PLLM = 8;

RCC_OscInitStruct.PLL.PLLN = 336;

RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;

RCC_OscInitStruct.PLL.PLLQ = 7;

if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)

{

_Error_Handler(__FILE__, __LINE__);

}

If I am disabling the bold marked code

if (HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK) is true otherwise false.

Posted on January 04, 2018 at 10:57

LSE is a low-power oscillator, basically a quite sensitive analog circuit. When powered from VDD, the bias conditions are different from when powered from battery.

'works when debugging' sounds like the LSE oscillator does start up but takes longer than when powered from battery; break into the loop waiting for LSERDY and single-stepping might then cover up this fact.

Try increasing the timeout.

I don' Cube so won't help with the details.

JW

Posted on January 04, 2018 at 11:02

We already did that and we also delayed the initial LSE configuration, no success :(

Posted on January 04, 2018 at 11:03

Here:

  ♯ define LSE_STARTUP_TIMEOUT    5000U     /*!< Time out for LSE start up, in ms */

Posted on January 04, 2018 at 11:23

Hi,

I am stunned but you're right. I was sure we tested that in the beginning but we must have done some debug bug.

When increasing LSE_STARTUP_TIMEOUT to 10000 it is working. But I also discovered another effect, if the debugger is connected (just physically connected and supplied, no in debug mode) it is also working with LSE_STARTUP_TIMEOUT == 5000

So you're absolute right, the oscillator is a delicate thing.

I'll test more but thanks a lot for your help.

Matthias

Posted on January 04, 2018 at 12:33

Probably one of those circumstances where you don't want to silently fail into a while (1) loop...

Problem with a lot of Cube/HAL example code is that it crawls off in a corner and dies if you get an error or abnormal situation.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Posted on January 04, 2018 at 11:42

It may sound surprising, but startup of a well-designed crystal oscillator depends on available noise, and more noise is better at that moment (and worse later when you want the oscillator be stable on as low power as possible). Connecting the debugger introduces this noise through various means (conducted, induction, common ground and ground loop effects etc.).

JW