[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Re: including default eeprom values in flash memory

From: Michael Clift
Subject: Re: [avr-gcc-list] Re: including default eeprom values in flash memory
Date: Fri, 23 Oct 2009 14:21:12 +1100
User-agent: Thunderbird (Windows/20090812)

Thanks David for your help, I didn't think of that. I'll put the check in, along with some warning notes for future reference.

David Brown wrote:
Michael Clift wrote:
Thanks for all the responses guys, some interesting ideas.
I don't really want to put all of my EEPROM data into one structure, as I have many eeprom variables with initializers distributed across a number of files.

What I ended up doing, was to change the .eep output format to binary, then I copied this to an object file as described here http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_binarydata I then linked this object into my main code. It works a treat, only I have to build my code twice to get the initial values updated to flash, once to create .eep, and again to link in the object.

When you do this, are you 100% sure that the addresses of the eeprom variables don't change? You have no guarantees about this, unless you work very hard with segment names and linker files. Far and away the safest and most reliable method is to put your eeprom data within a single defined structure. It is better to have to restructure your program a bit at this stage, than to stick with your scattered data approach and have weird bugs later when the order of data in the final build does not match that of .eep file build. It also makes it far easier to put it in a single build without using external utilities.

A poor but workable substitute would be to build in a check in your build process that confirms that that your linked .eep file matches the .eep file generated in the final build. You'll still get problems if you ever want to update the software in a system without reseting the eeprom to the flash defaults.

The main reason for doing this, is that I have a boot loader that I want our clients to be able to use, only the boot loader does not support eeprom loading. It also saves me having to program the eeprom in production.

Regards, Michael.

AVR-GCC-list mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]