Reprogramming PICAXE with USB stick - ie FIRMWARE UPDATE

mortifyu

New Member
Hi ALL,

Hoping to hear from the TOP guru's for this question.

I am toying with the idea of making an interface for the purpose of updating/reprogramming PICAXE chips with a USB memory stick.

EG.
I build a product with a PICAXE as the brains... Ultimately multiple PICAXE chips. Under normal operating conditions, the PICAXE's communicate with one another within the product.

What would be a supreme benefit would be to be able to send someone a USB memory stick with an updated program/programs on it so they could easily plug the USB stick into the product, turn it on and it automatically updates the PICAXE program/s.



I can appreciate I will need a USB interface of some sort, but exactly where to start and how to go about it?



Thanks for your input in advance guru's. Eagerly looking forward to your comments.



Regards,
Morty.
 

Circuit

Senior Member
Have a look at PICAXE Manual 2; booti2c command. This is the documented method of updating the internal program in a PICAXE chip with a new version. You need to create an interface to hook up an external i2c EEPROM. This will do what you require. I think that interfacing a USB stick is beyond what is possible with PICAXE.
 

inglewoodpete

Senior Member
I think that interfacing a USB stick is beyond what is possible with PICAXE.
The only way to program a PICAXE from a USB stick would be to put a computer running the programming editor in between the USB stick and the PICAXE ;)

Have a look at PICAXE Manual 2; booti2c command. This is the documented method of updating the internal program in a PICAXE chip with a new version. You need to create an interface to hook up an external i2c EEPROM. This will do what you require.
That option has some merit. The only limitations would be that the PICAXE would run a little slower than one running on internal flash and that you would have to use an X2-series PICAXE.

In my opinion, if you are going to the trouble of having the client replace an EEPROM chip then for only a slight increase in the overall cost, you may as well exchange the PICAXE chip with a freshly programmed one. Replacing the PICAXE chip would probably be only a small part of the cost if postage and labour are included.
 

Buzby

Senior Member
I have a plan that should work.

1, Build your remote devices with an X2, an I2C EEPROM, and a simple 'serial to USB' board.
Include an input pin to select a transfer mode. Tie this pin high.

2, Build your master device with the same components, but tie the input pin low.

3, Write two transfer routines. One to copy #slot 4 to a file on the USB, and one to copy the file on USB to #slot 4. This second routine ends with a booti2c command.
Also write a routine to detect the presence of a USB file.

4, Write your code as normal on the master, including the three routines.
Arrange the code so that at the start the 'low' pin causes the '#slot 4 to USB' routine to run.
Arrange that 'USB to #slot 4' is triggered if the pin is 'high' and a USB file is detected. Do this either by default at startup or by polling every few seconds as the code runs, the choice is yours.
( At this point the data copied to the USB file will just be whatever is in #slot 4, but we haven't put anything sensible in there yet. )

5, When you are happy with your master code, download to both #slot 0 and #slot 4.

6, Run the master.

Now if it all works as I expect, when the code runs on the master it will copy #slot 4 to the USB, then continue as normal.

If exactly the same code is initially loaded to a remote device, the 'high' pin will prevent the 'slot to USB' from running, and the code will continue as normal.
If a USB is detected then the 'USB to #slot 4' is triggered, and the booti2c at the end of the routine causes the code just copied from the USB to #slot4 to execute.

It's a bit long-winded, but I think it should work.

( Note : booti2c does not cause the executed code to run slower, it actually copies the #slot X to #slot 0 before running )

Cheers,

Buzby
 

Circuit

Senior Member
That option has some merit. The only limitations would be that the PICAXE would run a little slower than one running on internal flash and that you would have to use an X2-series PICAXE.

In my opinion, if you are going to the trouble of having the client replace an EEPROM chip then for only a slight increase in the overall cost, you may as well exchange the PICAXE chip with a freshly programmed one. Replacing the PICAXE chip would probably be only a small part of the cost if postage and labour are included.
My understanding of booti2c is somewhat at variance with this; you say that the PICAXE would run slower than one running on internal flash; that is not the case because the program is not run from the EEPROM. Booti2c tests the version of the existing program and the program on the connected EEPROM. If the program on the EEPROM is newer then the existing program is replaced in the PICAXE chip. Therefore, the EEPROM is built into an external and pluggable unit - which could be similar in size to a USB stick - and then used to update the PICAXE program slot when required. It is not left in place, the program is not run from it and it is only used to transfer the updated program to the PICAXE.

The advantage of this approach is that a simple pinned header or suchlike can be used to attach the updating EEPROM when required; the user is not confronted with the difficulty of changing a PICAXE chip.

See:http://www.picaxe.com/BASIC-Commands/Advanced-PICAXE-Configuration/booti2c/
 

Circuit

Senior Member
3, Write two transfer routines. One to copy #slot 4 to a file on the USB, and one to copy the file on USB to #slot 4. This second routine ends with a booti2c command.
Also write a routine to detect the presence of a USB file.
I know of absolutely no way to copy a code from a PICAXE slot out to a file; can I be enlightened?
 

Buzby

Senior Member
... Therefore, the EEPROM is built into an external and pluggable unit - which could be similar in size to a USB stick - and then used to update the PICAXE program slot when required. ...The advantage of this approach is that a simple pinned header or suchlike ...
This is a good idea. If you use a USB socket, but wired as I2C, and an EEPROM in a USB stick, it would look to all that it was USB, but it ain't.

And so much easier to code !.
 

Buzby

Senior Member
I know of absolutely no way to copy a code from a PICAXE slot out to a file; can I be enlightened?
readi2c : http://www.picaxe.com/BASIC-Commands/Advanced-IO-Interfacing/readi2c/

Just read the code from the i2c address corresponding to #slot X byte-by-byte. See booti2c for address details.

I did it when I thought I was going to need to bypass the booti2c version check, but as it was I didn't need to.

EDIT : Note, this only works with a slot in an external I2C EEPROM, not with internal slots 0 to 3.
 

AllyCat

Senior Member
Hi,

1, Build your remote devices with an X2, an I2C EEPROM, and a simple 'serial to USB' board.
I may be misunderstanding the process, but USB is a Host-Slave architecture and AFAIK neither a PICaxe nor a memory Stick can be a Host. The Host needs access to a "library" to know how to talk to the Slave.

But updating the PICaxe program via I2C from an external "slot" EEPROM (perhaps built into a "module") doesn't seem a great departure from the OP's original aim. EDIT: Ah, it seems you may have come to that conclusion in a later post.

Cheers, Alan.
 

Buzby

Senior Member
Hi, I may be misunderstanding the process, but USB is a Host-Slave architecture and AFAIK neither a PICaxe nor a memory Stick can be a Host
Hi Alan,

I used the wrong words, it's not a 'simple USB to serial', it's the Vdrive I suggested later.

But you are correct, if it only needs to look to the eye that it's USB, then a fake USB stick ( but really I2C ) would work very simply.

Cheers,

Buzby
 

inglewoodpete

Senior Member
My understanding of booti2c is somewhat at variance with this; you say that the PICAXE would run slower than one running on internal flash; that is not the case because the program is not run from the EEPROM. Booti2c tests the version of the existing program and the program on the connected EEPROM. If the program on the EEPROM is newer then the existing program is replaced in the PICAXE chip. Therefore, the EEPROM is built into an external and pluggable unit - which could be similar in size to a USB stick - and then used to update the PICAXE program slot when required. It is not left in place, the program is not run from it and it is only used to transfer the updated program to the PICAXE.

The advantage of this approach is that a simple pinned header or suchlike can be used to attach the updating EEPROM when required; the user is not confronted with the difficulty of changing a PICAXE chip.

See:http://www.picaxe.com/BASIC-Commands/Advanced-PICAXE-Configuration/booti2c/
This thread sure is clearing out some cobwebs! Yes, an external EEPROM chip and booti2c would re-flash an X2 PICAXE - something that I had misunderstood.
 

srnet

Senior Member
There are a number of other (low cost) microcontrollers that can read a SD card direct.

Thus if an I2C EEPROM was common between the two microcontrollers, it should be possible for the one with the SD card to disable the PICAXE temporarily, read the file from the SD card into the I2C EEPROM from where the PICAXE now boots.

The cost in parts for the 'other' micro is maybe £3 or less.
 

edmunds

Senior Member
I was looking into updating picaxe firmware a while ago and did some testing, too.

If the scope of your product/project allows to produce and 'proprietary firmware stick', then picaxe platform is probably as functional as any other with the advantage of simplicity of programming = maintenance.

I would refrain from exactly USB plug unless you can make sure your device is not damaged if plugged into computers, USB chargers and similar devices :).


Good luck,

Edmunds
 

hippy

Technical Support
Staff member
There are a number of other (low cost) microcontrollers that can read a SD card direct.
Including a PICAXE, though one has to produce the bit-banged code to do that. One could perhaps use an X2 which can be an I2C slave and read various blocks of file off the SD card and retrieve those.

Any auto-updating software scheme, especially with multiple PICAXE devices, is going to be complicated, and one has to wonder if the returns will ever justify the effort.

I would say the most important thing is to reflect upon the need, see if there are other ways to do it, including allowing parameter setting rather than complete reprogramming. Perhaps the biggest question is what the product is, why it will need updating, and how often. What is the product retail cost and how much income is reprogramming worth, how much would be lost without it.

They way I would probably approach this is to sell them an AXE027 cable and email them the updates they can program themselves. Or design it so they can remove the circuit board; you can send them a new one and have them return their old.
 

Circuit

Senior Member
Or design it so they can remove the circuit board; you can send them a new one and have them return their old...
Hippy, you have inspired me; I have been trying to think how I can run several different programs - a number beyond the slot capacity of the biggest PICAXE. I considered running from external i2c EEPROMs but I need the i2c function that is unavailable when the EEPROM is used for this purpose. I shall now look at designing a number of "program cartridges" with just the PICAXE chip mounted on a circuit board with the pins brought out on an edge connector. That way, I can have the main programs running from one chip and then a secondary cartridge with "maintenance mode" etc. loaded on it. I was thinking about moving this application over to the 32-bit Micromite system but this now keeps the design with my preferred PICAXE. Excellent!
 

SAborn

Senior Member
Why not just use "Team Viewer" its free for personal use, then you can log into the other persons computer and reprogram the chip via your own computer, that way no one else gets to see your code.
 
Top