2018-01-04 01:10 AM
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-rtcSolved! Go to Solution.
2018-01-04 02:57 AM
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
2018-01-04 01:24 AM
Show code (the offending part of it).
JW
2018-01-04 01:36 AM
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.
2018-01-04 02:57 AM
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
2018-01-04 03:02 AM
We already did that and we also delayed the initial LSE configuration, no success :-(
2018-01-04 03:03 AM
Here:
♯ define LSE_STARTUP_TIMEOUT 5000U /*!< Time out for LSE start up, in ms */
2018-01-04 03:23 AM
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
2018-01-04 03:33 AM
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.
2018-01-04 03:42 AM
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