samples\boards\stm32\backup_sram Backup sram contents retains even after power reset for nucleo f429zi board

[tanujapatgar-eaton]

Description Target Platform: STM32 board (nucleo f429zi) Build path: samples\boards\stm32\backup_sram After flashing the code, initially seeing current stored value as some garbage and if resets the board by pressing reset button current stored value incremented by 1. If power reset happens supposed to show current stored values as zero, but we were seeing some garbage values only. Attaching screenshot for reference.

Note enable the backup_sram node in overlay file and added here samples\boards\stm32\backup_sram

Steps to reproduce the behavior west build -b nucleo_f429zi -p samples\boards\stm32\backup_sram west flash

Expected behavior Each time the application runs the current value is displayed and then incremented by one. After power reset stored values supposed start from 0

Environment OS: Windows Toolchain: zephyr and gnuarmemb

[github-actions[bot]]

Hi @tanujapatgar-eaton! We appreciate you submitting your first issue for our open-source project. 🌟

Even though I'm a bot, I can assure you that the whole community is genuinely grateful for your time and effort. 🤖💙

[nordicjm]

Zephyr 3.2 is not supported, please confirm this issue is still present in a supported version of zephyr, ideally main, then edit your post to have the required information from https://github.com/zephyrproject-rtos/zephyr/blob/main/.github/ISSUE_TEMPLATE/001_bug_report.md

[erwango]

@tanujapatgar-eaton can you reproduce on recent Zephyr release ?

[tanujapatgar-eaton]

@erwango reproduce on 3.4.0 same issue

[FRASTM]

The fact is that the backup sram defined by the nucleo_f429 DTS is the backup_sram: memory@40024000 This section is the BKPSRAM of the stm32f429 device which differs from the (RTC) backup domain . It is mentionned in the RefMan RM0090 : "The BKPSRAM is not affected by this reset. The only way of resetting the BKPSRAM is through the Flash interface by requesting a protection level change from 1 to 0."

[erwango]

The fact is that the backup sram defined by the nucleo_f429 DTS is the backup_sram: memory@40024000 This section is the BKPSRAM of the stm32f429 device which differs from the (RTC) backup domain . It is mentionned in the RefMan RM0090 : "The BKPSRAM is not affected by this reset. The only way of resetting the BKPSRAM is through the Flash interface by requesting a protection level change from 1 to 0."

ok, then is there something that should be done about it ?

[FRASTM]

The stm32F2 stm32F405/F446 and stm32F7 have the same backup_sram block which is not affected by the power on/off or backup domain(BDCR) reset. The stm32H7 stm32H5 stm32U5 serie have their backup_sram block reset by power off on VBAT (VDD if connected)

[FRASTM]

At the time the samples/boards/stm32/backup_sram/ was introduced (by the PR stm32: add support for backup SRAM # 31702) same result on stm32f429zi or stm32f746zg nucleo boards :

*** Booting Zephyr OS build zephyr-v2.5.0-81-g68344cd87cba  ***
Current value in backup SRAM: 1013959382
Next reported value should be: 1013959383
Keep VBAT power source and reset the board now!

--> the nucleo board power off/on does not reset the content of the backup_sram If your application needs to reset the data at power on, then it should use the BOR flag as follows:

    if (LL_RCC_IsActiveFlag_BORRST()) {
        backup_data = 0; 
        LL_RCC_ClearResetFlags();
    }

[FRASTM]

@tanujapatgar-eaton What you observe is the expected hw backup_sram of the stm32f429

• power off ( Vbat off) does not reset the content of the bkup_sram (common feature of the stm32f2, stm32f7, stm32f4x)
• reset : the content of the bkup_sram is kept, like on any other stm32: stm32H5, stm32H7, stm32U5

[tanujapatgar-eaton]

At the time the samples/boards/stm32/backup_sram/ was introduced (by the PR #31702) same result on stm32f429zi or stm32f746zg nucleo boards :

*** Booting Zephyr OS build zephyr-v2.5.0-81-g68344cd87cba  ***
Current value in backup SRAM: 1013959382
Next reported value should be: 1013959383
Keep VBAT power source and reset the board now!

--> the nucleo board power off/on does not reset the content of the backup_sram If your application needs to reset the data at power on, then it should use the BOR flag as follows:

  if (LL_RCC_IsActiveFlag_BORRST()) {
      backup_data = 0; 
      LL_RCC_ClearResetFlags();
  }

after making these changes in zephyr\samples\boards\stm32\backup_sram\src\main.c

Observations:

power off: backup sram contents are not retaining board reset( pressing reset button): according to the main.c application value is incrementing by 1

@erwango @FRASTM

[erwango]

Moving to enhancement as requested behavior is not the exact purpose of the sample (see README)

[FRASTM]

Do you need a new sample application, adapted from the existing samples/boards/stm32/backup_sram/ and where "Each time the application runs the current value is displayed and then incremented by one. After power reset stored values supposed start from 0"

I propose https://github.com/zephyrproject-rtos/zephyr/pull/67194 @tanujapatgar-eaton, Please confirm the need for this new sample

[rzeeshan565]

Hi @tanujapatgar-eaton, I am trying to enable backup_sram for STM32f407VG. problem is I'm using a relatively older version of Zephyr (2.4.0). but I see you have used zephyr-v2.5.0. could you share your dts and example .c file?

After a lot of fixing dts here and there, I managed to reduce the error to this one.

error: 'DT_N_S_soc_S_memory_40024000_P_clocks_IDX_0_VAL_bus' undeclared here (not in a function); did you mean 'DT_N_S_soc_S_timers_40014000_P_clocks_IDX_0_VAL_bus'?

define DT_N_INST_0_st_stm32_backup_sram DT_N_S_soc_S_memory_40024000

                                      ^~~~~~~~~~~~~~~~~~~~~~~~~~~~