This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

RTC saved ram : how to disable zero init ?

Hi,

I'm using the RTC backup ram on a lpc23xx board in order to saved crucial varables.

But it seems it's always set to 0 at startup and I want to avoid that.

I'm using a scatter file and I define a rtc_ram section like this :

RW_RTCRAM 0xE0084000 0x000007FF { main.o (rtc_ram) }

I tried to use zero init at declaration , but It's always set to 0 :

volatile uc_saved_status_t uc_saved_status __attribute__((section("rtc_ram"),zero_init));

How can I bypass the init for the RTC ram ?

Thanks in advance

  • Note that zero_init is cleared variables. It forces the variable to be stored in a ZI memory section, i.e. that the startup code should clear it to zero on startup.

    www.keil.com/.../armccref_ciafccai.htm
    "The section attribute specifies that a variable must be placed in a particular data section. The zero_init attribute specifies that a variable with no initializer is placed in a ZI data section. If an initializer is specified, an error is reported."

    I just go for the simple solution. The project never mentions this memory area. Instead, I initialize a pointer to a struct in this memory. What the startup code does not know about, the startup code will not touch.

  • I tried with or without the 'zero_init' attribute. I did the same : set toi 0.
    I misunderstood the signification of this attribute :-/

    The pointer solution seems good, but I think I have to change a lot of things in my code. Moreover I have several struct in the rtc ram and then, I'll have to exactly know the adress of each.

    When you choose graphically the 'no init ' check box option for the linker, what is generated in the corresponding scatter file ?

  • It seems to add the attribute UNINIT in the scatter file does the job :

    RW_RTCRAM 0xE0084000 UNINIT 0x000007FF
    {
        main.o (rtc_ram)
    }
    

  • Remember to add a good checksum or similar to make sure that you can differentiate between uninitialized variables, and variables that have kept the state after a restart of the processor.

    Note that if the supply on the battery-supply pin runs low, you can get bit errors in the memory even if most of the variables looks ok. This is especially important if you have a super-cap that will only support a limited number of hours/days without power until reaching dangerously low voltage levels.