Knowing if battery backed-up SRAM is valid

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am about to start a project using an ATmega162 that can have 32 kB or 512 kB of external SRAM and started to wonder how am I going to know when I need to initialize the variables stored there. I really do not want to do a CRC check of the whole thing but I could since I have about 1 1/2 seconds of idle time during a 2 second power up delay.

I thought about adding a "magic" number but really could not think of a good one.

I have a packet count, head and tail pointer variables that will be stored in the external SRAM and those could be CRC'd but that doesn't do anything for the data. Should I keep a running CRC that gets stored after the last data packet?

For the big SRAM, I will have 8 banks of 64 kB which means I will be missing 8 time 1280 bytes used for the register, I/O and internal SRAM. I was wondering the technique shown in the datasheet to recover the missing bytes is really as easy as it seems?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Whats wrong with the magic number? Just dont use 0x0000 or 0xffff... they seem sort of likely to show up at power up.... but if you used 0x1234, your chance of getting that at power up is real small.....

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a few questions.

1. How much of your SRAM do you use for variable storage ? Surely you don't use the entire 512K for variables.

2. How do you initialize your variables now ?

Have you considered storing your variables in EEPROM (either inside the AVR or an external serial EEPROM ? On power-up you could copy data from EEPROM to SRAM.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@bobgardner:
The reason I really do not want a "magic" number is that I sort of went through this on an AT90S8515 project. The only way I could determine if a power-on reset versus a watchdog reset was to check SRAM. I normally use 0xC369 as my "magic" number but it failed on me as did several others.

@gahelton:
There are only three variables in external SRAM taking up a total of eight bytes. The rest is used for logging data. I thought about EEPROM (after I posted the question) for the variables but decided to keep them in external SRAM. It would be nice to know if the logged data is valid also.

While I am typing this, it occurred to me that a single bit error would invalidate all my data. Maybe I should have a CRC for the three variables and a CRC for each data packet. While I am at, maybe I should add PAR2 support :wink:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you wanted some security but not THAT much, you could do a CRC of parts of the memory. So CRC the first ten bytes, last ten bytes or something like that.

BTW in the "Academy" I have a CRC8/CRC16 routine that takes a pointer to data memory and a number of bytes to read. You could easily use this to just CRC your entire data memory by just pointing to XRAM and passing how much you have.

Though it might be slower - it doesn't use the table method.

Regards,

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I had not thought of doing two "sections" that have separate CRCs. I think it might be easier to CRC each logged data packet but I will definitely give it some thought. Because my data packets are not a constant size, I think it will be too difficult to keep checking the SRAM pointer for the other section so I do not overwrite it. Also because of banking for the 512 kB SRAM, I cannot simply just check the pointer itself.

I have a look-up table for an eight bit CRC routine that only uses 32 bytes of FLASH. I "add" the CRC for the low nibble to the previous CRC value and then "add" the CRC for the high nibble. I am pretty happy with it. It does have a weakness, data that is all zeroes will have a CRC of zero. There is another value that will also that fail if the rest of the data are zeroes. The other 254 values will change the CRC when a zero is "added" to it. So far it has not been a problem since I have been able to guarantee that the data cannot be all zeroes.