How can I individualise specific CPUs?

I wonder whether there is some approach to provide specific CPUs with
some program-readable identifier that allows to individually recognise
each CPU in a way that survives programming operations that start by
erasing the chip.

To be more clear, here is why I need this: I am having a bus with many
AT90CAN nodes, each of them driving timed events. The CPU clock of each
node is used to generate the necessary clock information. I use a
polynomic correction algorithm to correct hardware-specific clock
deviation, having a polynome which is specifically defined for each CPU
(resp. its PCB).

At present, I maintain a list of CPUs and their individual correction
polynomes and manually introduce them into the object code before a
device is re-programmed. That is a tedious and error-prone way of doing
(even if I store the polynome in eeprom and only need to adapt the
object code when eeprom is re-programmed).

I would like to automatize the manual procedure by some lookup algorithm
that uses a CPU id as a key. Has anybody come across this problem and
found a solution? The ideal way would be to have a zone of the eeprom (a
single byte would be enough) that is protected against
programming-triggered erasure, and that can be used by the application.

(Note: during normal operation, there is a DCF-driven master timer that
sends timer messages over the bus, allowing the nodes to synchronize;
but the system must continue to work even if temporarily the master
timer goes away - hence the need to adapt each node at least with a
basic timer-offset correction).


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Eric P.]

Dear Juergen,

What about an external SPI/I2C eeprom ?

Eric

----- Original Message -----
From: "Juergen Harms" <Juergen.Harms@...>
To: "avr-chat" <avr-chat@...>
Sent: Friday, September 18, 2009 9:45 AM
Subject: [avr-chat] How can I individualise specific CPUs?

>I wonder whether there is some approach to provide specific CPUs with
> some program-readable identifier that allows to individually recognise
> each CPU in a way that survives programming operations that start by
> erasing the chip.
>
> To be more clear, here is why I need this: I am having a bus with many
> AT90CAN nodes, each of them driving timed events. The CPU clock of each
> node is used to generate the necessary clock information. I use a
> polynomic correction algorithm to correct hardware-specific clock
> deviation, having a polynome which is specifically defined for each CPU
> (resp. its PCB).
>
> At present, I maintain a list of CPUs and their individual correction
> polynomes and manually introduce them into the object code before a
> device is re-programmed. That is a tedious and error-prone way of doing
> (even if I store the polynome in eeprom and only need to adapt the
> object code when eeprom is re-programmed).
>
> I would like to automatize the manual procedure by some lookup algorithm
> that uses a CPU id as a key. Has anybody come across this problem and
> found a solution? The ideal way would be to have a zone of the eeprom (a
> single byte would be enough) that is protected against
> programming-triggered erasure, and that can be used by the application.
>
> (Note: during normal operation, there is a DCF-driven master timer that
> sends timer messages over the bus, allowing the nodes to synchronize;
> but the system must continue to work even if temporarily the master
> timer goes away - hence the need to adapt each node at least with a
> basic timer-offset correction).
>
>
> _______________________________________________
> AVR-chat mailing list
> AVR-chat@...
> http://lists.nongnu.org/mailman/listinfo/avr-chat
>

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Thanks for the reply - that is a solution, but requires me to modify my
PCB, something I would like to avoid, at least for the moment.

Juergen


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Bernard Fouché]

Could you consider using a bootloader? (IIRC Atmel provides an
application note or some code to demonstrate how one can have a MCU boot
over the CAN bus).

Hence you don't perform a chip erase when you change your program (since
your application will be bootloaded cleanly).

Then you can keep your timing info either in EEPROM or in some bytes of
flash inside of the bootloader code area. (the later is better if you
make your devices able to also bootload EEPROM content).

So it's just when you flash the bootloader that the manual setup is done
once.

Juergen Harms wrote:

> I wonder whether there is some approach to provide specific CPUs with
> some program-readable identifier that allows to individually recognise
> each CPU in a way that survives programming operations that start by
> erasing the chip.
>
> To be more clear, here is why I need this: I am having a bus with many
> AT90CAN nodes, each of them driving timed events. The CPU clock of
> each node is used to generate the necessary clock information. I use a
> polynomic correction algorithm to correct hardware-specific clock
> deviation, having a polynome which is specifically defined for each
> CPU (resp. its PCB).
>
> At present, I maintain a list of CPUs and their individual correction
> polynomes and manually introduce them into the object code before a
> device is re-programmed. That is a tedious and error-prone way of
> doing (even if I store the polynome in eeprom and only need to adapt
> the object code when eeprom is re-programmed).
>
> I would like to automatize the manual procedure by some lookup
> algorithm that uses a CPU id as a key. Has anybody come across this
> problem and found a solution? The ideal way would be to have a zone of
> the eeprom (a single byte would be enough) that is protected against
> programming-triggered erasure, and that can be used by the application.
>
> (Note: during normal operation, there is a DCF-driven master timer
> that sends timer messages over the bus, allowing the nodes to
> synchronize; but the system must continue to work even if temporarily
> the master timer goes away - hence the need to adapt each node at
> least with a basic timer-offset correction).
>
>
> _______________________________________________
> AVR-chat mailing list
> AVR-chat@...
> http://lists.nongnu.org/mailman/listinfo/avr-chat
>

_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Great suggestions, many thanks.

Hardwiring unused I/O pins so far did not come to my mind, the necessary
soldering will be delicate but should be possible (TQFP64 packages).

Creating a bootloader has been on my todo list for a long time, so far I
managed to do without it. But reading your suggestion, I wonder whether
the bootloader idea has not an interesting side-issue which I might exploit:

  - reserve a minimum bootloader (512 words), but do not use a bootloader
    (keep the BOOTRST fuse unprogrammed),

  - store the CPU specific data in the bootloader flash section (playing
    with the lock bits to unprotect and later protect the bootloader
    again) - probably possible with a JTAG ICE and avrdude,

  - but: can a programme running in the application flash section read
    data from the bootstrap flash section? (the manual is explicit on
    writing, I did not find any info on reading) - I am optimistic, I
    interpret the lack of "prohibited" statements as an indication that
    data in that section can be read like any address in flash memory.

I will have to do some reading/playing around to see whether and how
this is feasible.

Juergen


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

I did not see the real problem: the "chip erase" required before
programming resets the lock bits. That means that downloading (parallel
or serial programming actions) will practically always also erase the
bootloader (unless the EESAVE fuse bit is programmed, but so far I
looked for a solution that allows to download into flash and eeprom).

Atmel evidently expects that either the bootloader is used more or less
exclusively, or the programming mechanism - but not the kind of
combination I had considered.

Too bad. An alternative would be to use the calibration eeprom byte (I
use an external crystal) - but that is a kind of approach which
interferes with settings that are probably better left as they are
shipped with the part.


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Peter LaDow]

On Fri, Sep 18, 2009 at 2:36 PM, Juergen Harms <Juergen.Harms@...> wrote:
> Atmel evidently expects that either the bootloader is used more or less exclusively, or the programming mechanism - but not the kind of combination I had considered.

I guess I didn't really understand your requirement.  But the above
seems to be a bit inaccurate.  You can access the bootloader region
from the application region.  In fact, in a previous project I worked
on the bootloader "exported" the flash write/erase functions to the
application.  In this way the application had write/erase access to
its own flash.  And using the mechanism it seems possible to have your
application update flash as necessary to store any calibration
information you need.

In our case, we had a "patch" mechanism whereby the firmware loaded
patches from an SD card and stored them in flash.  This was all done
by the application with support from the bootloader for flash
erase/write.

Pete


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Graham Davies]

> On Fri, Sep 18, 2009 at 2:36 PM, Juergen Harms wrote:
>> Atmel evidently expects that either the bootloader is used
>> more or less exclusively, or the programming mechanism
>> - but not the kind of combination I had considered.

Then, on Friday, September 18, 2009 to 6:00 PM, Peter LaDow wrote:
> I guess I didn't really understand your requirement.  But the above
> seems to be a bit inaccurate.  <snip>

What Juergen means, I think, is that when you change the application program
in a device, you either have a bootloader or you use a hardware programming
mechanism such as ISP, JTAG or (heaven forbid) High-Voltage.  With a
bootloader, you have a lot of freedom about what gets erased and what gets
preserved, but with a hardware programming mechanism you generally start
with a chip erase which wipes the entire Flash.  What Juergen wanted, if
I've been following correctly, is for a hardware re-program to leave the
contents of the boot loader section alone so that he could squirrel away his
"individualizations" there.

Graham.




_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Bill Gatliff]

Graham Davies wrote:
> What Juergen means, I think, is that when you change the application
> program in a device, you either have a bootloader or you use a
> hardware programming mechanism such as ISP, JTAG or (heaven forbid)
> High-Voltage.  With a bootloader, you have a lot of freedom about what
> gets erased and what gets preserved, but with a hardware programming
> mechanism you generally start with a chip erase which wipes the entire
> Flash.  What Juergen wanted, if I've been following correctly, is for
> a hardware re-program to leave the contents of the boot loader section
> alone so that he could squirrel away his "individualizations" there.

Such "personalizations" might include end-user-supplied data or options,
calibration values that are learned in-situ, etc.  Stuff that can't be
known prior to reprogramming the device, unless you read it out of the
device before wiping it.

So yea, it would be nice to have tighter control over what gets erased
during a firmware update...


b.g.

--
Bill Gatliff
bgat@...



_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Even if the immediate result does not show an easy solution, this
discussion (and needing to put in writing what I think) has helped -
many thanks - and yes, Grahams interpretation describes precisely what I
want, sorry for the need to be interpreted.

I am at present wondering about an alternative, based on re-considering
my use of eeprom: continue (evidently) to use eeprom for storing data
that must survive boots, but rather than initialising the eeprom
contents by download, define a condition which triggers initialisation
of the contents of eeprom by program-controlled transfer from flash (for
instance, trigger the transfer when at boot-time a specific eeprom byte
contains 0xFF). That would allow to always maintain the EESAVE bit
programmed and keep my private data in some "reserved corner" of eeprom.
My application could probably live with such an approach - still needs
some thinking about.

Juergen


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Peter-35]

Juergen Harms schrieb:

>
> I am at present wondering about an alternative, based on
> re-considering my use of eeprom: continue (evidently) to use eeprom
> for storing data that must survive boots, but rather than initialising
> the eeprom contents by download, define a condition which triggers
> initialisation of the contents of eeprom by program-controlled
> transfer from flash (for instance, trigger the transfer when at
> boot-time a specific eeprom byte contains 0xFF). That would allow to
> always maintain the EESAVE bit programmed and keep my private data in
> some "reserved corner" of eeprom. My application could probably live
> with such an approach - still needs some thinking about.
>
> Juergen

What about modifying your upload-script to first download one byte of
the eeprom, then create a second eeprom.hex file from your master
eeprom.hex file, in which you change the byte to the value read with the
"srecord" tool, and then writing it back?

Greetings,
Peter


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[David VanHorn-2]

A while back,  I wrote a little routine called fuser.asm that fixes
the CKOPT fuse in M128 parts.

That code could be adapted, and put in a larger chip with a usart, so
that a PC could tell it what the customizations are, and it could go
change them, without needing the intermediate hex file step.


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Thanks, that is a good solution.

I have solved my problem by simply disabling the chip erase for eeprom
(program the EESAVE fuse byte and suppress any download to eeprom),
compiling object-code for eeprom into a template in flash and than
initialising EEPROM - when and where needed - by programmed transfer
from this template.

I create the eeprom address space by allocating non-initialised
variables as target for receiving the copy from the flash template - may
sound complicated but is very easy to realize (attention is only needed
where the template needs to contain eeprom addresses). The intialisation
of the flash-to-eeprom transfer is triggered at boot when key-bytes in
eeprom contain 0xFF (hence if the eeprom is void). In case
re-initialisation of eeprom becomes necessary, that can be triggered by
forcing these bytes to 0xFF.

That works out nicely for my application (I have much more flash
capacity than I need, and timewise there does not appear to be a penality).


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Daniel O'Connor-3]

On Wed, 23 Sep 2009, Juergen Harms wrote:

> I create the eeprom address space by allocating non-initialised
> variables as target for receiving the copy from the flash template -
> may sound complicated but is very easy to realize (attention is only
> needed where the template needs to contain eeprom addresses). The
> intialisation of the flash-to-eeprom transfer is triggered at boot
> when key-bytes in eeprom contain 0xFF (hence if the eeprom is void).
> In case
> re-initialisation of eeprom becomes necessary, that can be triggered
> by forcing these bytes to 0xFF.
>
> That works out nicely for my application (I have much more flash
> capacity than I need, and timewise there does not appear to be a
> penality).

When I did this I used a checksum at the end - if it didn't match it
would load rewrite EEPROM from the hard coded flash version.

/* Holds all the settings needed */
typedef struct {
    uint8_t fermenter_ROM[8];
...
} __attribute__((packed)) settings_t;

/* Current settings in RAM */
static settings_t settings;

/* Our map of EEPROM */
struct {
    settings_t settings;
    uint16_t crc;
} ee_area __attribute__((section(".eeprom")));

/* Defaults that are shoved into EEPROM if it isn't inited */
const PROGMEM settings_t default_settings = {
    .fermenter_ROM = { 0x10, 0x8b, 0x7a, 0x53, 0x01, 0x08, 0x00, 0xb4 },
};

Then you can write to it with..
    eeprom_busy_wait();
    eeprom_write_block(&settings, &ee_area.settings,
                        sizeof(settings_t));
    dptr = (uint8_t *)&settings;
    crc = 0;
    for (i = 0; i < sizeof(settings_t); i++)
        crc = _crc16_update(crc, dptr[i]);

    eeprom_write_word(&ee_area.crc, crc);

(I always block write it)

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

[Daniel O'Connor-2]

On Wed, 23 Sep 2009, Juergen Harms wrote:

> I create the eeprom address space by allocating non-initialised
> variables as target for receiving the copy from the flash template -
> may sound complicated but is very easy to realize (attention is only
> needed where the template needs to contain eeprom addresses). The
> intialisation of the flash-to-eeprom transfer is triggered at boot
> when key-bytes in eeprom contain 0xFF (hence if the eeprom is void).
> In case
> re-initialisation of eeprom becomes necessary, that can be triggered
> by forcing these bytes to 0xFF.
>
> That works out nicely for my application (I have much more flash
> capacity than I need, and timewise there does not appear to be a
> penality).

When I did this I used a checksum at the end - if it didn't match it
would load rewrite EEPROM from the hard coded flash version.

/* Holds all the settings needed */
typedef struct {
    uint8_t fermenter_ROM[8];
...
} __attribute__((packed)) settings_t;

/* Current settings in RAM */
static settings_t settings;

/* Our map of EEPROM */
struct {
    settings_t settings;
    uint16_t crc;
} ee_area __attribute__((section(".eeprom")));

/* Defaults that are shoved into EEPROM if it isn't inited */
const PROGMEM settings_t default_settings = {
    .fermenter_ROM = { 0x10, 0x8b, 0x7a, 0x53, 0x01, 0x08, 0x00, 0xb4 },
};

Then you can write to it with..
    eeprom_busy_wait();
    eeprom_write_block(&settings, &ee_area.settings,
                        sizeof(settings_t));
    dptr = (uint8_t *)&settings;
    crc = 0;
    for (i = 0; i < sizeof(settings_t); i++)
        crc = _crc16_update(crc, dptr[i]);

    eeprom_write_word(&ee_area.crc, crc);

(I always block write it)

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat

Thank you, nice to have code just to copy from.

That brings up a second question: are there any guidelines how paranoiac
to be with checksumming of data in eeprom?

Reread-verify after download is an evident necessity - one extreme; I
certainly will not checksum what I write to RAM, the other extreme.
Between these extremes, where situate EEPROM writes? The reply is
certainly hardware/manufacturer specific - how reliable are writes to
internal eeprom of an Atmel processor?


_______________________________________________
AVR-chat mailing list
AVR-chat@...
http://lists.nongnu.org/mailman/listinfo/avr-chat