STM32F401, F405, F407, f4xx? backup registers about arduino_stm32

[stevstrong]

Hm, the core is using the value according to STM32F405/407 manual (DocID022152 Rev 8) page 73, the BKPSRAM address of 0x4002 4000.

So what exactly do you mean that is not correct?

[stevstrong]

Ah, I see what you mean, I entered the SRAM address instead of RTC & backup register address which is 0x4000 2800.

[ag88]

hi steve,

i've uploaded codes for my local copy of bkp.h and bkp.c in a gist
https://gist.github.com/ag88/c4429b0e77b58e2b3d461798d6021dd5

what is missing here is a test or more appropriately example sketch to use it. After reviewing the various specs and manual.
i think it is fairly safe to conclude that stm32 f4xx has 20 backup registers all 32 bits and for the larger chips they have addition of 4KB backup sram. the specs i've reviewed are only
(only 20 backup registers) f401, f411,
(20 backup registers + 4kb sram) f405, f407, f427, f429, f439)
i'm not sure about other f4xx outside this range

in my use case, i'm using the backup registers on stm32f401 with RTC, i.e. RTC is initialised on LSE and the registers are write enabled. so i'm not too sure if bkp.h, bkp.c alone is adequate to use the backup registers. it would take me a little time to create the test/example sketch and i can create that in a PR for roger's core if you prefer.

one other thing is i've deleted the rtc related defines from bkp.h as they don't seem relevant to stm32f4. the full codes is in the gist link above

* RTC Clock Calibration Register */

#define BKP_RTCCR_ASOS_BIT              9
#define BKP_RTCCR_ASOE_BIT              8
#define BKP_RTCCR_CCO_BIT               7

#define BKP_RTCCR_ASOS                  BIT(BKP_RTCCR_ASOS_BIT)
#define BKP_RTCCR_ASOE                  BIT(BKP_RTCCR_ASOE_BIT)
#define BKP_RTCCR_CCO                   BIT(BKP_RTCCR_CCO_BIT)
#define BKP_RTCCR_CAL                   0x7F

/* Backup control register */

#define BKP_CR_TPAL_BIT                 1
#define BKP_CR_TPE_BIT                  0

#define BKP_CR_TPAL                     BIT(BKP_CR_TPAL_BIT)
#define BKP_CR_TPE                      BIT(BKP_CR_TPE_BIT)

/* Backup control/status register */

#define BKP_CSR_TIF_BIT                 9
#define BKP_CSR_TEF_BIT                 8
#define BKP_CSR_TPIE_BIT                2
#define BKP_CSR_CTI_BIT                 1
#define BKP_CSR_CTE_BIT                 0

#define BKP_CSR_TIF                     BIT(BKP_CSR_TIF_BIT)
#define BKP_CSR_TEF                     BIT(BKP_CSR_TEF_BIT)
#define BKP_CSR_TPIE                    BIT(BKP_CSR_TPIE_BIT)
#define BKP_CSR_CTI                     BIT(BKP_CSR_CTI_BIT)
#define BKP_CSR_CTE                     BIT(BKP_CSR_CTE_BIT)

i'm also not too sure about the 4KB sram part as i'm only testing it on stm32f401 currently that doesn't have the additional 4kb backup sram

[stevstrong]

It looks ok, you can push a PR to Roger's core, I will then check it.

[ag88]

edit: reading a little further in rm0009

under section 2.3 Memory map , BKPSRAM is at 0x4002 4000
then in section 5.1.2 battery backup domain - backup domain access
"
• Access to the RTC and RTC backup registers

1. Enable the power interface clock by setting the PWREN bits in the RCC_APB1ENR
   register (see Section 7.3.13 and Section 6.3.13)
2. Set the DBP bit in the Section 5.4.1 and PWR power control register (PWR_CR) for STM32F42xxx and STM32F43xxx to enable access to the backup domain
3. Select the RTC clock source: see Section 7.2.8: RTC/AWU clock
4. Enable the RTC clock by programming the RTCEN [15] bit in the Section 7.3.20: RCC Backup domain control register (RCC_BDCR)

• Access to the backup SRAM

1. Enable the power interface clock by setting the PWREN bits in the RCC_APB1ENR
   register (see Section 7.3.13 and Section 6.3.13 for STM32F405xx/07xx and
   STM32F415xx/17xx and STM32F42xxx and STM32F43xxx, respectively)
2. Set the DBP bit in the PWR power control register (PWR_CR) for STM32F405xx/07xx
   and STM32F415xx/17xx and PWR power control register (PWR_CR) for
   STM32F42xxx and STM32F43xxx to enable access to the backup domain
3. Enable the backup SRAM clock by setting BKPSRAMEN bit in the RCC AHB1
   peripheral clock enable register (RCC_AHB1ENR)."

I'd guess we can enable that in bkp_init(). step 1 and 2 seem to be common.
we can add step 3 for the sram part.

But for the backup registers, apparently users would need to initialise rtc (e.g. rtc.begin(). it so happens that in my case rtc is running. note that i've also customized my copy of RTClock.cpp. rtc.begin() checks if LSE_ON is set. if LSE_ON is set (i.e. LSE running), i skipped backup domain reset and resetting the time and date. This is to allow rtc.begin() to be called on power up and that VBAT is maintained by a coin cell but it should not reset/clear the existing running rtc.

and we can perhaps define a macro in bkp.h
#define BKPSRAM_BASE 0x40024000UL // Backup SRAM(4 KB) base address
this define is found in the cmsis header in the official core for stm32f407
https://github.com/stm32duino/Arduino_Core_STM32/blob/master/system/Drivers/CMSIS/Device/ST/STM32F4xx/Include/stm32f407xx.h

keeping the 'old' somewhat compatible libmaple backup register bkp.h functions is useful as it would enable apps to be written for both libmaple f1 and f4 cores without if-defs, even if at hardware level it is literally different. stm32f103c8 is a 'subset' of stm32f4

[ag88]

It looks ok, you can push a PR to Roger's core, I will then check it.

thanks, i'd do so in the next few days, note there is no hurry with this whatsoever.
i just happen to start using this and i just thought i'd 'tidy up' some of the use cases related to bkp and rtc.
i used rtc to provide date and time for sd fat and used a bkp register as a 'coulomb counter', tracking the hours run on rechargable batteries.

[stevstrong]

I reopen the issue until we adapt the backup functionality as you indicated above.

[ag88]

just a little update on progress. Currently it is still 'work in progress', a sample run on stm32f401cc black pill looks like this.
this is just for the backup registers.

init
bkp values:
reg :1:0
reg :2:0
reg :3:0
...
reg :18:0
reg :19:0
reg :20:0
setting bkp values:
bkp values:
reg :1:100001
reg :2:100002
reg :3:100003
...
reg :18:100018
reg :19:100019
reg :20:100020

i've verified that they persist across reset and remains there if vbat is maintained. RTC is initialised and running on LSE.

updated codes are currently on the gist as it isn't ready to commit
https://gist.github.com/ag88/c4429b0e77b58e2b3d461798d6021dd5

i've done some works on BKPSRAM and the next thing is to test the same on 'stm32f407 black' board, i'd need to search for the board and set it up probably need a new coin cell. some additional convenience functions related to bkp_sram are in bkp.h. those would be tested as well next.

other changes are in RTClock begin(). if LSE is on i skipped initialization so that time maintained by VBAT won't be erased.
this would allow users to simply have rtc.begin() in setup without having to work around LSE running on VBAT and avoid resetting the RTC. reading a few round in the manuals, i'd think this is appropriate. LSE, RTC and backup domain is only maintained if LSE is running on VBAT. otherwise if is is unplugged and replugged it would go back to unselected or LSI which is default.

[ag88]

ok the PR is done
rogerclarkmelbourne#850
works on stm32f407ve black board (bkp registers and bkp sram) and stm32f401 black pill (bkp registers)
sample run

init
bkp values:
reg :1:100001
reg :2:100002
...
reg :19:100019
reg :20:100020
BKPSRAM 2nd byte:63
BKPSRAM 2nd uint16 word:10676
BKPSRAM 2nd uint32 word:3105925270
BKPSRAM text at offset 10:s@▒▒+1▒▒▒▒▒
A▒▒vu@▒r▒v▒|▒/▒P7W%▒O▒▒
setting bkp values:
bkp values:
reg :1:100001
reg :2:100002
...
reg :19:100019
reg :20:100020
BKPSRAM 2nd byte:100
BKPSRAM 2nd uint16 word:10000
BKPSRAM 2nd uint32 word:1000000
BKPSRAM text at offset 10:a quick brown fox jumps over the lazy dog

after reset looks like this

init
bkp values:
reg :1:100001
reg :2:100002
...
reg :19:100019
reg :20:100020
BKPSRAM 2nd byte:100
BKPSRAM 2nd uint16 word:10000
BKPSRAM 2nd uint32 word:1000000
BKPSRAM text at offset 10:a quick brown fox jumps over the lazy dog
setting bkp values:
bkp values:
reg :1:100001
reg :2:100002
...
reg :19:100019
reg :20:100020
BKPSRAM 2nd byte:100
BKPSRAM 2nd uint16 word:10000
BKPSRAM 2nd uint32 word:1000000
BKPSRAM text at offset 10:a quick brown fox jumps over the lazy dog

edits are limited to
bkp.h, bkp.c - re-written - pretty much
rccF4.h - added RCC_AHB1ENR_BKPSRAMEN
example in STM32F4/libraries/RTClock/examples/BkpTest

[ag88]

one more thing, i've made some changes in RTClock.cpp.
this is so that rtc.begin() would not clobber time on a running RTC if it is running on LSE and VBAT.
https://gist.github.com/ag88/c4429b0e77b58e2b3d461798d6021dd5#file-rtclock-cpp
I've tested them several rounds and the changes are stable on stm32f407ve black and stm32f401cc black pill.
it is a useful update. can i include them in this PR? at the moment i've only updated codes in my gist so that it can be reviewed

[stevstrong]

Feel free to include it in the PR.

[ag88]

thanks, i've added the commit.
note that i've modified Test_RTClock example during my regression tests.
https://gist.github.com/ag88/c4429b0e77b58e2b3d461798d6021dd5#file-test_rtclock-cpp
among the changes
it seemed rtc.begin() is not called in setup(). that is necessary or normally freezes / hardfaults would happen.
i've made various other edits for the interactivity changes and commented codes changing the weekday, for some reason i've not figured out, the weekday changing codes tend to clobber a RTC that is already running ok.
the example is not in the commit and only in my gist in the above link

[stevstrong]

The changes were merged from the upstream repository.