CubeMX BUG: Setting LSE Drive Capability

[Clonimus74]

Posted on October 17, 2017 at 12:08

When using CubeMX, with STM32L476, for setting LSE drive capability other than 'Low Drive' the setting will not be implemented. This is due to the fact that the write access using bit DBP in PWR->CR1 is not set prior to setting RCC->BDCR value.

The code generated in SystemClock_Config is:

void SystemClock_Config(void)

{

RCC_OscInitTypeDef RCC_OscInitStruct;

RCC_ClkInitTypeDef RCC_ClkInitStruct; RCC_PeriphCLKInitTypeDef PeriphClkInit;

/**Configure LSE Drive Capability

*/ __HAL_RCC_LSEDRIVE_CONFIG(RCC_LSEDRIVE_LOW);

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

*/ RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_LSE|RCC_OSCILLATORTYPE_MSI; RCC_OscInitStruct.LSEState = RCC_LSE_ON; RCC_OscInitStruct.MSIState = RCC_MSI_ON;....

}

where HAL_PWR_EnableBkUpAccess must be executed prior to 

__HAL_RCC_LSEDRIVE_CONFIG

#cubemx #lse

[Nesrine M_O]

Posted on October 17, 2017 at 15:50

Dear

Ofri.Igal

,

Are you using the last CubeMX version ? if no please use the latest.

If this issue persist with the 4.1 version please tell us.

-Nesrine-

[Clonimus74]

Posted on October 17, 2017 at 19:16

Mine is 4.22.0, downloading the new version now and I will update

[Clonimus74]

Posted on October 17, 2017 at 19:38

Same problem in 4.22.1

Also, the function that come later, HAL_RCC_OscConfig, does set the 

DBP bit, but never clears it at the end, so the access is permitted until the next reset and it doesn't make sense.

[Jeanne Joly]

Posted on February 06, 2018 at 16:55

Hi

Sorry for my late answer.

However, on top of CubeMX4.24, I can't see the issue you reported.

__HAL_RCC_LSEDRIVE_CONFIG took the parameter enter in the RCC configuration tab (even if LSE Drive Capability is set to a value other than LSE oscillator low drive capability).

If you still see this issue with the current CubeMX release, could you please send me your ioc in order that I analyze it in depth?

Thanks in advance. Jeanne

[Clonimus74]

Posted on February 07, 2018 at 09:14

The problem doesn't occur when using

using the LL driver in 

CubeMX4.24 (STM32Cube_FW_L4_V1.11.0)

It still happens when using HAL driver, here is the code of 

SystemClock_Config from cube, the first instruction is __HAL_RCC_LSEDRIVE_CONFIG before enabling 

DBP in PWR->CR1 

void SystemClock_Config(void)

{

RCC_OscInitTypeDef RCC_OscInitStruct;

RCC_ClkInitTypeDef RCC_ClkInitStruct; RCC_PeriphCLKInitTypeDef PeriphClkInit;

/**Configure LSE Drive Capability

*/ __HAL_RCC_LSEDRIVE_CONFIG(RCC_LSEDRIVE_MEDIUMLOW);

.

.

.

.

I have no idea how to attach you the ioc file :)

[Jeanne Joly]

Posted on February 08, 2018 at 09:44

Hi

Ofri.Igal

,

To insert your ioc file, please, click on 'insert image' button even if it is an ioc file (it won't check the extension type).

BR. Jeanne

[Jeanne Joly]

Posted on February 08, 2018 at 10:03

Hi

Ofri.Igal

again,

It seems that this issue has just been seen by our development team. I will get back to you as soon as the correction is available.

BR. Jeanne

[Jeanne Joly · Accepted solution]

Posted on March 20, 2018 at 17:42

Hi

Ofri.Igal

,

This issue is now fixed in the current CubeMX release.

Please, upgrade with CubeMX4.25 if not already done.

BR. Jeanne

[liteyear]

For anyone still having trouble getting this setting to stick, even with the correct call to  HAL_PWR_EnableBkUpAccess() first, consider another gotcha:

Like other backup domain register fields, writing to LSEDRV requires the DBP bit in PWR_BDCR1 to be set. But unlike other fields, it also requires LSEON and LSERDY to be clear (ie. that is, the external 32kHz oscillator to be disabled). What makes this tricky is that those bits are loaded from the backup domain. So if you've enabled LSE previously they will already be set on boot.

I think there's three ways around this:

1. reset the backup domain via software first, by setting BDRST bit RCC_BDCR.

2. reset the backup domain via hardware, by power cycling VDD and VBAT.

3. clear LSEON first and wait for LSERDY to clear.

Methods 1 and 3 require some hacking that you'll probably want to remove after the job is done. Method 3 has less collateral impact, although I haven't tested it.

Method 2 is something you can do without changing the code - you just have to be sure those supplies are completed drained. If you have any sort of hold-up on them this may take a while. Note this also means you'll never see it happen in the debugger - it happens on the first cold boot, and by the time you attach a debugger the backup domain will be back in charge.