Has RCC_AHB1Periph_BKPSRAM been replaced by RCC_AHB1ENR_BKPSRAMEN_Msk?

Forum|Forum|3 years ago
February 23, 2023
5 replies
1267 views

Legacy:

RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_BKPSRAM, ENABLE);

RCC_APB1PeriphClockCmd(RCC_APB1Periph_PWR, ENABLE);

Current: ?

RCC_AHB1PeriphClockCmd(RCC_AHB1ENR_BKPSRAMEN_Msk, ENABLE);

RCC_APB1PeriphClockCmd(RCC_APB1ENR_PWREN_Msk, ENABLE);

This topic has been closed for replies.

RobmarAuthor

Senior II

Like this? :-

#include <stm32f4xx_hal_rcc.h>

#include <stm32f4xx_hal_rcc_ex.h>

#include <stm32f4xx_ll_pwr.h>

__HAL_RCC_PWR_CLK_ENABLE();

HAL_PWR_EnableBkUpAccess();

__HAL_RCC_BKPSRAM_CLK_ENABLE();

LL_PWR_EnableBkUpRegulator(); // Wait until backup regulator is initialized

while (!LL_PWR_IsActiveFlag_BRR());

// Then one can write to it like this: *(__IO uint8_t *) (BKPSRAM_BASE + offset) = x; You can read from it like this: uint8_t x = (*(__IO uint8_t *) (BKPSRAM_BASE + offset));

Is it necessary to call:

HAL_PWR_DisableBkUpAccess();

In case of power failure?

waclawek.jan

Super User

> RCC_AHB1Periph_BKPSRAM

This is some SPL-specific symbol.

Authors of "libraries" such as SPL and Cube for some inexplicable reason have an urge to define various symbols haphazardly, without any system of any kind. To cope with them is one of the bonuses of subscribing to usage of such "libraries".

In register-level access, I recommend you to stick to symbols from the CMSIS-mandated device header (such as RCC_AHB1ENR_BKPSRAMEN_Msk which - as you can look up easily in that header - is identical to RCC_AHB1ENR_BKPSRAMEN). Those symbols are created in a relatively systematic way, more-less matching registers and bits/bitfield names in RM.

If you wish to use "libraries", use whatever symbols are recommended for that particular "library", reading documentation coming with that "library" or its sources for the list of allowable parameters to any public function or macro.

As you might've guessed by this point, I don't use Cube, but whatever you do, think twice if it's a good idea to mix HAL and LL. And definitively avoid mixing SPL with any form of Cube.

If you're asking about the hardware, whether backup SRAM requires to switch off the backup domain access switch - no, it's switched off automatically when upon powerdown/brownout the mcu goes into reset, as OFF is it's reset state. You do use an appropriate level of brownout when using battery-backuped RAM, don't you.

However, it may be a good practice to enclose all BKPSRAM accesses into backup-domain-enable/backup-domain-disable, to protect it against accesses from spuriously runaway program. It is lengthier, though, so you may want to weight the relatively small benefit against the execution time/code spent on this.

In any case, don't forget to switch on the low-power backup regulator, as described in Backup SRAM subchapter of PWR chapter in RM (if it's STM32F407, see PWR_CSR.BRE, probably similar or same for other 'F4 too) (you appear to do it in above code, just wrote it to be sure).

JW