Reprogramming while keeping old data?

[jadney]

I'm working on a project where I need to calibrate each board to remove errors due to resistor tolerances. To do this, I plan to run each board thru a 30 second calibration routine on its first power up. This will result in calibration values specific to that board being saved in the picaxe chip. It's possible, even likely, that I will want/need to reprogram boards with different firmware as the project matures, but I'd like to do this without losing the calibration numbers.

Is there a way to reprogram the picaxe chip without clearing all the stored data? As a last resort, I know I could download the data, write it down, enter it in the reprogramed software, but that's going to be a real burden in the long run.

What I'd really like would be a suggestion of a place in memory that would remain non-volatile during reprogramming. Failing that, I wonder if I could write a program that would read specific bytes, reprogram the picaxe, then write those specific bytes back.

FYI, I'm only talking about 5 bytes of data.

thanks,

 

[AllyCat]

Hi,

You've not specified which PICaxe chip, but the answer is probably much the same for most of them.

You can use the EEPROM memory (aka the DATA or Read/Write memory) with a #NO_DATA directive at the top of the program, to instruct it NOT to download (overwrite) the data memory. Obviously you need to avoid Read/Write commands to the addresses of the calibration bytes in the program (except when updating them). Some chips also have Table memory (another 256 bytes) with a corresponding #NO_TABLE command, but you may need to check how these two directives interact with each other. The table cannot be written from within the program.

But you might want to use an additional backup identification/storage method as all the data will be lost if you accidentally reprogram without the #NO_DATA directive.

Cheers, Alan.

 

[hippy]

As AllyCat suggests; #NO_DATA is what you need.

This prevents overwriting existing Data EEPROM when a program which has that included is downloaded.

To counter forgetting to include that, accidentally wiping calibration data, it is best for the calibration program to output its calibration values with SERTXD so these can be written down and manually re-entered should it come to that.

 

[jadney]

Sorry, been out of town for a few days.

I'm using the PICAXE-08M2. It's small, but it does everything I need for this project.

Thanks for the suggestion. It looks like I need to buy a better manual, since the one I've been using does not mention any commands starting with #. Okay, up to date manual ordered. ;-)

If I put #NO_DATA at the beginning, can I still write specific data later in the program? If possible, I'd like my program to check a byte to see if it's been set to some particular value, like 11111111, that would indicate that the calibration had already been run. If not, run the calibration routine and then write the calibration values and 11111111 as a flag to EEPROM that calibration had been done. Once calibration has been done, the 11111111 flag would cause the calibration portion of code to be ignored.

Does this sound reasonable?

One more question: If this works, I'll expect the firmware to run thousands of times thru thousands of power-ups over many years. Can I trust the PICAXE to work reliably and not suffer corruption of the data or code? I understand that I will have to protect the chip from noise/spikes on its power rail or I/O pins. Are there special vulnerabilities I should be aware of?

thanks,

 

[Aries]

The # "commands" are DIRECTIVES (see the front of the manual section between Symbols and Variables). As I understand it (and have always used it), all that #NO_DATA does is to skip any DATA xx,(xx) statements (see under EEPROM in the manual). References to data within the program (READ/WRITE) still work.

 

[westaust55]

However,
The #No_Data directive does not apply for the 08M2 parts.

See:http://www.picaxe.com/BASIC-Commands/Directives/hash-no-data/

 

[AllyCat]

Hi,

I need to buy a better manual,

You hardly need to buy a better manual, almost everything you need is free on the "Basic Commands" and "Manuals" tabs at the top of the forum pages.

But as Aries says, you do need to "know" that the # commands are "Directives". However, I'm not sure he is right that #NO_DATA only skips DATA (aka EEPROM) commands. AFAIK the compiler will write zeros to the EEPROM unless #NO_DATA is used*. It's quite easy to know (but might be too late!) because (at least with PE5) the programming "ribbon" makes a second pass (or maybe three with larger chips with Table memory) to write the EEPROM data. Many of us regularly use #NO_DATA simply to make programming faster.

The EEPROM memory is rated to at least 100,000 write operations and doesn't appear to be at all "volatile". There are probably Microchip Application Notes if you're really interested. Of course all the normal supply decoupling and over-voltage measures should be used. If there is any "weak link", it might be "Leg 4" of the 08M2 (the "input only" pin, C.3) because it's the "High Voltage" Programming /Reset pin on the base PIC chip. As such it doesn't have an electrostatic "catching" diode to the supply rail. There's no risk that it could "reprogram" the chip, but it would be wise not to connect that pin to a long external cable or to true RS232 voltage levels, for example.

*WA55 raises an interesting point: On the 08M2 the DATA/EEPROM memory is "borrowed" from the top 256 bytes of Program memory (or technically I believe it's the other way around) so perhaps zeros won't be written. But if you don't have a "dummy" DATA command and a #NO_DATA , might not the Program "take back" the bytes for its own use?

Cheers, Alan.

 

[hippy]

The #No_Data directive does not apply for the 08M2 parts.

I don't think that's correct, I believe it is a documentation error but I would have to verify that.

#NO_DATA doesn't entirely ignore any DATA commands; it simply doesn't download any data to be written into EEPROM.

 

[jadney]

I don't think that's correct, I believe it is a documentation error but I would have to verify that.

If I look at what the programming editor says, it says it applies to the 08M2, among others. When I added the #NO_DATA command to my program and ran a syntax check, it didn't complain.

 

[jadney]

Hi,

You hardly need to buy a better manual, almost everything you need is free on the "Basic Commands" and "Manuals" tabs at the top of the forum pages.

Right, I know, but for things like this, I really prefer paper books. It's probably the generation I'm from, but I'm stuck with that.

AFAIK the compiler will write zeros to the EEPROM unless #NO_DATA is used*.

Yeah, that's the part that interests me. The book I had does not make it clear that programming clears everything to zeros before it starts.

The EEPROM memory is rated to at least 100,000 write operations and doesn't appear to be at all "volatile". There are probably Microchip Application Notes if you're really interested. Of course all the normal supply decoupling and over-voltage measures should be used. If there is any "weak link", it might be "Leg 4" of the 08M2 (the "input only" pin, C.3) because it's the "High Voltage" Programming /Reset pin on the base PIC chip. As such it doesn't have an electrostatic "catching" diode to the supply rail. There's no risk that it could "reprogram" the chip, but it would be wise not to connect that pin to a long external cable or to true RS232 voltage levels, for example.

Okay, good info. I'll be especially careful with that pin. It's also good to know that the other pins have catch diodes. In the long term, what I'm more worried about is program corruption due to electrical noise, vibration, temperature swings, or cosmic rays. This is an automotive application. The PC board will be in a nice steel box, but automotive applications can be challenging. I just don't want the program to suddenly start misbehaving after a few months in use.

*WA55 raises an interesting point: On the 08M2 the DATA/EEPROM memory is "borrowed" from the top 256 bytes of Program memory (or technically I believe it's the other way around) so perhaps zeros won't be written. But if you don't have a "dummy" DATA command and a #NO_DATA , might not the Program "take back" the bytes for its own use?

I understand that I'll have to be careful about where I load program variables and keep them separate from the calibration data that I need to preserve. I don't understand your "dummy" DATA command comment; care to elaborate?

 

[procfanousek]

If I remember correctly from this forum, PICAXE chips are not recommended for critical automotive applications. Maybe you can find something useful in this thread:
http://www.picaxeforum.co.uk/showthread.php?14857-How-to-protect-picaxe-in-vehicle-use

 

[AllyCat]

Hi,

Technically, I believe the 08M2 has 1792 bytes of program memory but larger programs can use also the 256 bytes of EEPROM memory to give a full 2048 bytes "slot", like the other M2s. A subtlety here is that the EEPROM memory cells may permit a larger number of write cycles than Program memory cells. However, this extra program space will "disappear" if a DATA statement "reserves" the EEPROM bytes. IIRC the bytes are actually allocated from the top down, so if you only declare EEPROM address 0 then the program may still have 2047 bytes available?

But the compiler can't know which address will be written at run time by something like WRITE b0,b1 so I don't see how the above could be implemented. Maybe hippy (or Technical) will come along with an explanation but, I suggest that the program should be limited to 1792 bytes and also you include a DATA/EEPROM statement which allocates bytes to your calibration constants, even though they won't be written if there is a #NO_DATA directive.

Certainly the forum moderators do discourage "amateurs" to write (any) "safety-critical" program code. Also, strictly, the PICaxe chips probably do use only "Consumer" PIC versions rather than the "Industrial" variants (which should include automotive). But there are numerous posts on the forum which consider the PIC(axe) chips to be about as bomb proof as you can get.

Cheers, Alan.

 

[hippy]

In the long term, what I'm more worried about is program corruption due to electrical noise, vibration, temperature swings, or cosmic rays. This is an automotive application. The PC board will be in a nice steel box, but automotive applications can be challenging. I just don't want the program to suddenly start misbehaving after a few months in use.

Though a PICAXE should not start misbehaving, no one can guarantee it won't at some time in the future, and that applies to any microcontroller system.

This is why we do not recommend using microntrollers including the PICAXE in any safety critical system and advise against that.

When a microcontroller is used in a safety critical system that system must be designed to be tolerant to complete failure of the microcontroller and/or anything else connected to it.

Even when it's not a part of a safety critical system per se care has to be taken when connecting to an automotive system; one doesn't want a power issue on the board or other adverse occurrence to burn out the wiring harness, interfere with the accelerator, brakes or other safety critical systems.

If you could let us know what kind of 'automotive application' you are thinking of there may be more specific advice which can be given.