Sign In
Forgot Password?
Sign In | | Create Account

Memory signature follow-up

Colin Walls

Colin Walls

Posted May 30, 2011
0 Comments

I recently posted some thoughts about handling non-volatile RAM – dealing with the recognition of memory that had not been initialized. I was very pleased to hear from a couple of readers readers, Bert Böhne in the Netherlandsand Gary Lynch in the US, who have some experience in this matter …

Bert tells us:

“In a current project we do the same. We have some non-volatile memory for settings. After each set of data we also defined one byte for a crc. When we write a set of data, we calculate the crc and write it to the memory. Each time when read a set of data we also calculate the crc. Then we check if the calculated crc is the same as crc which is read back. When the board comes from the fabric the memory data is 0×00 on each address. The calculation of the crc will then return 0×00. This would cause a match of calculated and read back crc. To overcome this, we added an offset to the crc calculation. By doing this we now that we already wrote a set of data, and that the data is correct.”

This is a very simple and elegant solution to the problem. My approach of using a signature enabled the state of the RAM to be determined very quickly [by interrogating a 32 bit value], without having to do an checksum or CRC calculation. I am just wondering whether in this case they can just check that the CRC is non-zero to see that the RAM is not initialized?

Gary shares with us:

“I have been warehousing user data in non-volatile memory for decades. The best approach I have come up with is to break the memory space into small pieces and protect each piece with an 8-bit checksum. Breaking it up prevents one alpha particle from wiping out your whole database. My current preference is 7 bytes of data to one byte of checksum.

“Since a block of all 0′s will read back as correct, I define one item in each block such that 0 is not a valid number. I believe this is sufficient to tell the difference between a virgin device and one my control has previously programmed.

“My controls can lose power at any time, so I have a circuit in front of the voltage regulator to issue a ‘You have n msec until power fails’ warning, at which point I wrap up all write operations (most NV memory technologies require saving data in blocks and take up to 10 msec to complete a write operation) and suspend writes until power fails or the signal goes away.

“As I said, we’ve been shipping systems with this scheme in place for years, and we’ve never had a customer complain about a control serving up garbage as valid data.”

Again, another straightforward, pragmatic approach. Thanks for sharing guys.

Memory, non-volatile memory, NVRAM

More Blog Posts

About Colin Walls Follow on Twitter

Colin WallsI have over twenty-five years experience in the electronics industry, largely dedicated to embedded software. A frequent presenter at conferences and seminars and author of numerous technical articles and two books on embedded software, I am a member of the marketing team of the Mentor Graphics Embedded Systems Division, and am based in the UK. Away from work, I have a wide range of interests including photography and trying to point my two daughters in the right direction in life. Learn more about Colin, including his go-to karaoke song and the best parts of being British: http://go.mentor.com/3_acv Visit The Colin Walls Blog

More Posts by Colin Walls

Comments

No one has commented yet on this post. Be the first to comment below.

Add Your Comment

Please complete the following information to comment or sign in.

(Your email will not be published)

Archives

 
Online Chat