RF over the air Firmware Update
Moderators: David Barker, Jerry Messina
RF over the air Firmware Update
Hello, I'm working on a product that uses a PIC18F25K22 and has RF radio communication via the UART, and I'm tinkering on doing an over the air firmware flash option.
Let me illustrate what I have in mind so far...
the product application is considerable small (around 6K Bytes) and I have 32K available, let say that I reserve 12K for program Area In which will have a function to receive the radio packets of the new firmware and write them on free flash memory, let say starting $3000, after all the packets are received and verified to be fine and complete, the program will jump to a Flash memory Copy routine starting at $7000, that will move the whole block from $3000-$5FFF and put it on $0000-$2FFF, and after doing this will self reset...
I haven't done much yet, did some tests writing and moving Flash memory blocks successfully, but before I get deep into this I would love to hear some opinions, about this approach...
Any input is welcome...
Thanks in advance
Sergio
Let me illustrate what I have in mind so far...
the product application is considerable small (around 6K Bytes) and I have 32K available, let say that I reserve 12K for program Area In which will have a function to receive the radio packets of the new firmware and write them on free flash memory, let say starting $3000, after all the packets are received and verified to be fine and complete, the program will jump to a Flash memory Copy routine starting at $7000, that will move the whole block from $3000-$5FFF and put it on $0000-$2FFF, and after doing this will self reset...
I haven't done much yet, did some tests writing and moving Flash memory blocks successfully, but before I get deep into this I would love to hear some opinions, about this approach...
Any input is welcome...
Thanks in advance
Sergio
-
- Swordfish Developer
- Posts: 1471
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: RF over the air Firmware Update
That sounds workable to me.
One suggestion might be to have the first step of the copy routine replace the reset vector @ $0000 with a 'jump $7000'.
That way if anything goes wrong during the copying it'll automatically jump back into the copy routine at reset.
Have the copy routine skip replacing the first 64-byte block @ $0000 until the last step.
There's still a chance that this could screw up and leave things unbootable but the chances are lessened.
Another more foolproof option would be to never reprogram the block at $0000, and treat your copy routine like a bootloader so it always runs at startup.
The copy routine could even have provisions to verify the two blocks and copy/run them as appropriate.
This way you always have a valid program to run, and if you locate the copy routine in low memory instead of the top
you can write-protect it too. The 25K22 has a 2K-byte boot block ($0000-$07FF), so as long as the bootloader fits into that space you're good.
That would leave you with two 15K blocks for your program and the download.
One suggestion might be to have the first step of the copy routine replace the reset vector @ $0000 with a 'jump $7000'.
That way if anything goes wrong during the copying it'll automatically jump back into the copy routine at reset.
Have the copy routine skip replacing the first 64-byte block @ $0000 until the last step.
There's still a chance that this could screw up and leave things unbootable but the chances are lessened.
Another more foolproof option would be to never reprogram the block at $0000, and treat your copy routine like a bootloader so it always runs at startup.
The copy routine could even have provisions to verify the two blocks and copy/run them as appropriate.
This way you always have a valid program to run, and if you locate the copy routine in low memory instead of the top
you can write-protect it too. The 25K22 has a 2K-byte boot block ($0000-$07FF), so as long as the bootloader fits into that space you're good.
That would leave you with two 15K blocks for your program and the download.
Re: RF over the air Firmware Update
hi Jerry...
As allways thanks for the prompt comment and excelent input...
Now I feel confident to jump at it and start using the aproach you sugested...
Will let you know how all this works...
Best Regards
Sergio
As allways thanks for the prompt comment and excelent input...
Now I feel confident to jump at it and start using the aproach you sugested...
Will let you know how all this works...
Best Regards
Sergio
Re: RF over the air Firmware Update
It works...!
I did the Flash Copy Routine on High Memory, it uses less than 256 Bytes!! so i put it on $07F00
the file receive and verify has to be part of the main program
this allow for almost 16K program flash...
Haven't played yet with reset vector to have a little more strenght, but dont think I need that for this aplication...
the only problem incurred was to wait on the sending computer a few millisecons after each serial block is sent to allow the PIC for erase and write the 64 bytes block.
Regards
Sergio
I did the Flash Copy Routine on High Memory, it uses less than 256 Bytes!! so i put it on $07F00
the file receive and verify has to be part of the main program
this allow for almost 16K program flash...
Haven't played yet with reset vector to have a little more strenght, but dont think I need that for this aplication...
the only problem incurred was to wait on the sending computer a few millisecons after each serial block is sent to allow the PIC for erase and write the 64 bytes block.
Regards
Sergio
Re: RF over the air Firmware Update
Been working on this for a few days, and is working good so far...
just a quick one... to jump to the Flash Write routine I use the GoTo <Label> command...
where <Label> points to the flashing Routine, on following versions I will not include the Flashing routine (also no label)...
is posible to have somenthing like GoTo <Address> like Goto $7F00?
just a quick one... to jump to the Flash Write routine I use the GoTo <Label> command...
where <Label> points to the flashing Routine, on following versions I will not include the Flashing routine (also no label)...
is posible to have somenthing like GoTo <Address> like Goto $7F00?
-
- Swordfish Developer
- Posts: 1471
- Joined: Fri Jan 30, 2009 6:27 pm
- Location: US
Re: RF over the air Firmware Update
Easiest way is just to do a simple asm block. Here's two examples. If you use the second one you must have the number in a format mpasm understands.
Code: Select all
const APP_PROGRAM_ADDR = $7F00 'can use SF formatted number
asm
goto APP_PROGRAM_ADDR
goto 0x7F00 ; number must be in mpasm format
end asm
Re: RF over the air Firmware Update
Any chance of getting some sample code posted for this?
Over the air firmware update is something thats been on my wish list for a long time, but so much other business always gets in the way of me investigating it.
Its nice when we give back to the swordfish community
Jason.
Over the air firmware update is something thats been on my wish list for a long time, but so much other business always gets in the way of me investigating it.
Its nice when we give back to the swordfish community
Jason.