Executing a function only once

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Executing a function only once

2,121 Views
LordMark
Contributor IV

Hi everybody. I'm using M52259DEMOKIT.

 

I need to execute an initialization function only once. After reset or power loss it doesn't have to be called unless it is scheduled during my application. Any suggestions?

 

I already reserved the portion of RAM that is battery backed up for some variables that I could use as flag or similar, but I'm still getting problems. I'm really going crazy for this to work :smileyvery-happy: Maybe for you it may be a simple problem to solve. 

 

Regards,

Marco

Labels (1)
0 Kudos
Reply
7 Replies

1,547 Views
scifi
Senior Contributor I

Obviously, you need non-volatile memory to implement this. Why not use on-chip flash memory?

0 Kudos
Reply

1,547 Views
LordMark
Contributor IV

I've already tried it using flash, and obviously it works. But I was wondering if it is possible to avoid using it...

0 Kudos
Reply

1,547 Views
kef
Specialist I

Isn't compiler startup routine initializing your flag variables in battery backed RAM? You should prevent it. To do so you should place your flag variable in custom memory section like this:

 

in *.c file:

 

#pragma define_section noinit ".noinit" far_absolute RW
__declspec(noinit) int flag;

 

in *.lcf file:

 

  .noinit :
  {
    *(.noinit)
    . = ALIGN (0x4);
  } >> userram

 

0 Kudos
Reply

1,547 Views
LordMark
Contributor IV

The memory section I created is not initialized by startup code. 

0 Kudos
Reply

1,547 Views
kef
Specialist I

So what's the problem?

 

1. At startup you check if your NV variables contain some non-random pattern.

2. a) if pattern is random (you didn't write it, RAM chip generated it in your flags variable), then  you execute writeonce() and write non-random patten to NV flags.

   b) if pattern is non-random, then you skip executing writeonce()

 

For better robustness you could checksum some NV locations and write checksum to another NV location. Checksum will reduce the risk that some RAM chip generates matching pattern in flag variable.

There may be an issue with how long was MCU not powered. If RAM was unpowered not long enough, then some bits may have flipped to ramdom state, some not. To reduce risk of not executing writeonce() when required, checksumed area should be longer. Also you need to change (invert) all checksumed locations from their default state and write new checksum to NV.

etc..

0 Kudos
Reply

1,547 Views
LordMark
Contributor IV

Yes, I know. My issue is: how to check for random pattern? :smileywink:

 

You are also talking about the risk of flipping bits. Is it reported anywhere? I thought the first 16kbytes of RAM and RTC could be powered without problems untill 1.8V. 

0 Kudos
Reply

1,547 Views
kef
Specialist I

OK (not really). You insert battery into errr .. standby battery socket for the first time. You power you board, maybe run into main() and stop there. Startup routine didn't clear your custom memory area, so NV RAM doesn't contain zeros but something. You have declared flag variable like this

 

__declspec(..) int flag; // allocated not in .bss, .sbss, .data, or .sdata memory sections, so startup doesn't clear it

 

So you didn't writte into flag after last Vstb power on. What does flag contain? Most likely it won't contain all zeros or all ones, most likely ir will be something like 0x547ABf0, random bits pattern. And you define some less random pattern, say 0xaa55aa55, 0xa55a5aa5, 0xC0DEBEEF, etc. It is not very likely to find such pattern in RAM after power on. So you read flag, compare it to 0xaa55aa55 or other not very expected "random" power on values and decide to think RAM was powerd off, or not to think that RAM was powered off. etc

 

Regarding risk of flipping bits. I meant that if you power off RAM for too short, pattern in RAM may or may not revert to "random" state. In case flag is the same like you wrote it, other locations in RAM may already have some bits flipped.

 

0 Kudos
Reply