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 RAM problem of LPC2378

Dear all
I am storing some variable(normal variable, unsigned char ,int, float ,char Array etc.) in RTC RAM.
After some time processor stop execuation.If I delete all RTC RAM variable from program,and downloading hex file again.but still it is not working.

what will happened? How can I erase RTC RAM?
waiting for your reply...

Shyam T
Pune India.

Parents
  • Are you storing pointers in the battery-backed RAM?
    You should try to just store configuration (even better to use a flash sector for this) and state information that must survive a reboot or power loss in the battery-backed RAM.

    Your application _must_ be written in a way that main() starts to validate the contents before it may start to use it. If the contents is found to be broken (for example not matching a crc-32 evaluatinon) your program should explicitly clear all variables and set them to suitable default values.

    When you release an application, that application must survive even if you get random bits that loose their contents in the battery-backed RAM. Maybe you are using a super-cap that can supply power for hours up to weeks. But when the voltage goes down, you will get bit errors. Possibly you have a lithium or silver-oxide button cell. But if the user replaces that battery, they may do it just fast enough that you get a partial loss of data.

    A program that does not survives this is a dangerous program...

    So, keep update your application until it can start and run no matter what contents you have in this RAM.

    By the way - exactly how are you powering the nonvolatile RAM?

Reply
  • Are you storing pointers in the battery-backed RAM?
    You should try to just store configuration (even better to use a flash sector for this) and state information that must survive a reboot or power loss in the battery-backed RAM.

    Your application _must_ be written in a way that main() starts to validate the contents before it may start to use it. If the contents is found to be broken (for example not matching a crc-32 evaluatinon) your program should explicitly clear all variables and set them to suitable default values.

    When you release an application, that application must survive even if you get random bits that loose their contents in the battery-backed RAM. Maybe you are using a super-cap that can supply power for hours up to weeks. But when the voltage goes down, you will get bit errors. Possibly you have a lithium or silver-oxide button cell. But if the user replaces that battery, they may do it just fast enough that you get a partial loss of data.

    A program that does not survives this is a dangerous program...

    So, keep update your application until it can start and run no matter what contents you have in this RAM.

    By the way - exactly how are you powering the nonvolatile RAM?

Children
  • yes I am storing pointer variables in battary backup ram.I am using silver-oxide button cell for battary power.
    Can u tell me how to use flash sector for storing user variables?
    and also tell me how to errase RTC ram?
    by removing battary cell is it possible to errae battary back up ram?

  • You clear the battery-backed RAM just like you clear any other RAM:

    memset(NVRAM_PTR,0,NVRAM_SIZE);
    

    The NXP datasheet contains information how to use IAP to write to flash sectors. You do not use flash sectors to store "variables", since the flash supports a limited number of write cycles, and you have to erase the flash sector before writing to it. But the flash sectors are excellent for storing configuration.

    By removing the battery, the contents in the RAM will deteriorate. But there is no guarantee that the RAM will end up in any given state. All you are allowed to know is that after removal of the battery, the RAM will be in an unknown state.

    But as I have already said: You should not worry so much about how to erase the RAM - you should worry about writing an application that works even with broken contents in the RAM. Any other solution is a broken solution. Since the result of using a broken pointer is fatal, you should avoid storing pointers in this RAM - and if you do, you should then "protect" your pointers by a high-end checksum so you can decide with a very high probability if the pointer values are valid or if they are broken.