Best way to store s no ,calib coeff and program for units

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

Hi Freaks,
Say I am making a large volume of AVR application units.
What is the best way to store a unique serial number (or unit ID),calibration coefficients (say for a sensor) and the application code for the AVR for the different units? I would also like to lock my program and serial number.The calibration coefficients can change in the field so I want them rewritable.
Thanks.

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

A good way to store your unique serial number data and calibration data is the AVR's internal EEPROM.

A file containing the default calibration data and a reserved area for the serial number will need to be created and assembled/compiled. A seperate, external program will need to keep track of serial numbers,increment as necessary, and modify the contents hex or eep file used to store the serial number. Each time that a device under test (DUT) is successfully programmed and calibrated, the external serial number monitor will increment the serial number, and write the new data to the EEPROM file to be programmed into the next micro.

The hex and eep file formats are very simple ASCII files representing the hex values to be stored and the addresses. You can do an internet search for "hex file format" to find out more information.

The calibration data can either be self calculated by the DUT and stored in EEPROM, or it can be generated externally, then sent to the micro. In either case, it should be the DUT's responsiblity to store the calibration data into it's internal EEPROM.

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

So since both the serial numbers and the application code will be in EEPROM, will the micro decide where in EEPROM the serial number will be stored? Or can I specify the EEPROM address for the serial number in the code? How about flash? Can I store the serial number in flash? Does the cal. data have to be in EEPROM or can it be in flash as well?

What I understand from your comments is that the application code and the serial number will be converted into an Intel hex file which will go into EEPROM (or flash?) and then I will change the lock bits to lock the EEPROM.

However for the cal. data and to be written to the EEPROM, would a section of the EEPROM have to remain unlocked so the AVR can write to it?

How about a bootloader? Should I load my app. code into the bootloader?

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

Application code will not go into EEPROM, only the serial number and calibration values. Application and bootloader code will ALWAYS go into flash on an AVR.

You can certainly specify the addresses of the serial number and calibration values in EEPROM. Typically for EEPROM storage, I use assembly rather than C because it's simpler and generally easier to specify fixed addresses.

There are no locks for EEPROM. The application code will just have to know not to write to the serial number location, or overwrite the calibration values unless the proper conditions allow an overwrite.

You can certainly have a bootloader if you want. This will allow you to upgrade application code without the use of a JTAG or ISP programmer. But, this doesn't have any bearing on serial number or calibration value storage in EEPROM.

There is a distiction between the bootloader code and the application code. Usually, the bootloader does not run the application. Instead, the bootloader performs minimal initialization then checks the application memory area with a memory check (CRC, checksum, etc). If the check is ok, then the bootloader will jump to the application section to begin the application code. If the memory check is not ok, the code will remain in the bootloader section and wait for a signal to begin "fixing" the application code.

You can have locks on the different sections of flash. Typically, I would set the locks on the bootloader section so it doesn't get overwritten, but leave the applicaton section unlocked so updates can occur.

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

If it is possible to have another component on the board, then a so called "1-wire serial number IC with EEPROM" would provide the functionality that you are looking for, e.g. DS2431 from Maxim.

Since the 1wire chip is an external component which is accessed by a special protocoll, the data stored in the EEPROM can't be accidently destroyed. The serial number in the chips can't be modified in any way.

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

I prefer to store serial number / mac id in the bootloader code and then access it using something like the following:

define in bootloader code like this

const prog_char mac_id[] = {0x40, 0x00, 0x00, 0x00, 0x00, 0x02 };

read from application with something like this

mac1 = pgm_read_byte_far( MACADDR1 );
mac2 = pgm_read_byte_far( MACADDR2 );
mac3 = pgm_read_byte_far( MACADDR3 );
mac4 = pgm_read_byte_far( MACADDR4 );
mac5 = pgm_read_byte_far( MACADDR5 );
mac6 = pgm_read_byte_far( MACADDR6 );

where MACADDRx is the actual flash address of the mac_id array.

This way, you never lose things that shouldn't change like mac id when changing the eeprom... assuming that your bootloader stays intact with lockbits set.

I store editable calibration coefficients in eeprom with crc. If the crc is incorrect on startup, I assume eeprom corruption and reset to defaults.

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

Quote:

Typically, I would set the locks on the bootloader section so it doesn't get overwritten, but leave the applicaton section unlocked so updates can occur.

Wouldn't this be dangerous? I would like to lock the application code to prevent it from being hacked/corrupted because once I deploy the board to the field, I am not looking to modify the app.code.

Also isn't flash more reliable than EEPROM as far as data corruption is concerned? Storing the cal. coeff. in flash seems like a better idea. I know I would still have the write cycle limitation with flash but I am not looking to update the coefficients that often.

@uracolix:
The one wire does sound attractive. I guess it still has a code overhead due to the protocol plus maybe longer access times/delays for read/write?

Quote:

I store editable calibration coefficients in eeprom with crc. If the crc is incorrect on startup, I assume eeprom corruption and reset to defaults.

So looks like I may have to write a bootloader to check both the EEPROM with the cal. coefficients and the flash for the application code.

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

Quote:
npat_avr
Wouldn't this be dangerous? I would like to lock the application code to prevent it from being hacked/corrupted because once I deploy the board to the field, I am not looking to modify the app.code.

If you aren't ever going to update application code or coefficents, then just store everything in flash memory and set the lock bits. Sounds like you don't need a bootloader. You can access the coefficents and serial number from your application code as I mentioned in previous post.

Don't forget the diode on the reset line.

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

Quote:
I guess it still has a code overhead due to the protocol plus maybe longer access times/delays for read/write?

Certainly it is not the fastest way, but usually this data are read once at startup and buffered in RAM. I have currently no idea about the code size for a 1 wire driver, but here I found a tiny45 project, that does a USB to DSxxxx converter: http://www.mulder.franken.de/ds1...

Another advantage imho is, that the chip can be read/write directly from the pads with a reader (for production and service purposes).

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

You can store your serial number into the flash applicaton code if desired. You will still need an external program for serial number management which modifies the applicaton, or EEPROM hex file with the serial number data.

One way of doing this would be to reserve a page of flash (or more if needed) for permanent data storage which can vary between individual processors (like serial number and calibration values). These values could be uploaded to the product and self programmed via the bootloader.

If you chose to go this route, you will need a bootloader since you can't be running code in the application section while you're programming there. Although, it seems like a bit of waste to have a bootloader to program "parameters" into flash. That's what EEPROM is for.

As far as reliabilty, EEPROM is no less reliable than Flash. Most EEPROM problems are cause by inproper operation during low voltage conditions (people didn't turn on brown-out detect), or when trying to write to EEPROM while power is going down (insufficient time to complete write before total power loss).

If you are just going to write your serial number and calibration values once to EEPROM with no futher writes, there should be no advantage to storing them in Flash as long as reset is controlled.

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

Thanks,guys.

Quote:

One way of doing this would be to reserve a page of flash (or more if needed) for permanent data storage which can vary between individual processors (like serial number and calibration values). These values could be uploaded to the product and self programmed via the bootloader.

This may be a separate post but ,how do I write a bootloader from scratch? Any pointers/links/tutorials will help.
I would like to try a simple bootloader program to say write a constant value to a location in flash just to get started and then move on to more complex stuff.

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

Quote:

This may be a separate post but ,how do I write a bootloader from scratch? Any pointers/links/tutorials will help.
I would like to try a simple bootloader program to say write a constant value to a location in flash just to get started and then move on to more complex stuff.

A bit like LCD support - what is the point in wasting time and re-inventing the wheel? There are a couple of GREAT bootloaders in the Project section here - just use one of those. If you do want to write on yourself then I believe you use GCC in which case you are bound to start with but if you do that you will just hit the example at the top of the file which is pretty much a pre-written solution anyway (worked fine for me anyway)

http://www.nongnu.org/avr-libc/u...

Cliff

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

Ok thanks, Cliff.

Also I noticed the FAQ section on bootloaders in the tutorials. Will also go through that. So for now, I think the following is what sounds like the best way to store my snos, etc. for my app.

Serial number: EEPROM
Calibration factor: EEPROM
Application code: Flash (locked)
Diode on reset line. 
Enable BOD.

What kind of control circuit do I need for my Reset line? How should I connect the diode?

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

Most AVR systems need nothing more than a pull-up resistor on the reset line (10K seems to work well). No capacitance should be added to the reset line if you intend on using DebugWire.

You can even completely disable the external reset pin and rely entirely on the internal power on reset and brown-out reset. But, that will prevent further programming unless you use high voltage mode to recover the device (this is a major pain with a device soldered to your PCB). Typically, I don't disable reset with the fuse, and just add a 10K pull-up resistor to the reset line.

I have no idea where the diode idea comes from with respect to the reset line. But I can tell you that I have many designs with only a 10K pull-up resistor on the reset line with no problems.

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

gahelton wrote:
**But, that will prevent further programming unless you use high voltage mode to recover the device ***

I have no idea where the diode idea comes from with respect to the reset line. But I can tell you that I have many designs with only a 10K pull-up resistor on the reset line with no problems.

Heheh.. you do have an idea...

Just kidding... I have lots of designs without the diode too, but it really should be there mostly for ESD protection and also for potential HV programming event.

see here:
http://www.atmel.com/dyn/resourc...

As the doc mentions, don't put it on there if you are using HV programming.

[edit]
On second thought, you could put a 15v TVS diode on there if you are using HV programming (I never do), and still get some ESD protection...

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

I should have known about the diode :) I know most chips will have an ESD protection diode one to supply pin and another to GND for most pins except maybe RF and supply pins.

In this case,the AVR does not have the internal diode on the RESET pin since you need high voltage if you are using high voltage programming.

But wouldn't the external diode be slower to act to a high voltage event (like ESD) than an internal diode? I know there are ESD specs that define the pulse width and amplitude, etc. (which always bothers me because how can you have a spec. for an event that cannot be controlled like the human fingers with lots of charge built up?) but maybe you have to select a diode which would ideally match the internal ESD diode of the chip on the pin (had there been one).