View previous topic :: View next topic |
Author |
Message |
JamesW
Joined: 23 Apr 2007 Posts: 91 Location: Rochester, England
|
If I wanted to do a bootloader on a PIC24 - what choices? |
Posted: Wed Sep 26, 2018 8:28 am |
|
|
Hi Folks,
Hypothetical question. I've got a PIC24 in a system running great, and doing just what I need it to. It's connected via a modem to a web server that we've also created and all is hunky dory.
If I wanted to add to the system the ability to reprogram the processor remotely, what options do I have?
I do have a spare EEPROM space on the board - where potentially I could fit a 1Mbit I2C eeprom - if that is an option, although there is always the phobia of it not copying across the code right and failing.
Don't mind changing the board, don't mind adding a 2nd processor to do it.
Needs to be pretty bullet proof though.
Ideas on a postcard please.
Thanks
James |
|
|
newguy
Joined: 24 Jun 2004 Posts: 1908
|
|
Posted: Wed Sep 26, 2018 9:00 am |
|
|
Bootloader: http://www.smallridge.com.au/ (why reinvent the wheel?)
Very satisfied customer of Andrew's SD card driver. If I had a need for an ethernet bootloader, Andrew would be the first person to whom I would turn.
On a side note, my present employer is facing the same issues and questions you are presently contemplatiing. We're leaning toward a 1Mb SPI EEPROM with extra overhead code running in the main application to do a rigorous check on any new image. We are also looking at a mechanism to keep not only the new image but also the last image. In that manner, if there is something very obviously wrong with the new image, at least the end user can force it to revert to the previous image. |
|
|
Ttelmah
Joined: 11 Mar 2010 Posts: 19518
|
|
Posted: Wed Sep 26, 2018 10:09 am |
|
|
Newguy makes the critical point. "rigorous check on any new image".
At the end of the day you can do a bootloader in protected memory space on the PIC24. Have it load from the EEPROM. Then have extra code in your "main" that reads the file, and does checksum and validity checks on this before storing this, and setting a bit to signal to the bootloader code to actually perform the programming.
You can do exactly the same with an external PIC, which then programs the main chip.
In both cases the bootloader/programming code looks for a flag in the EEPROM to perform the programming. This is only set once you have verified the code is correct. |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1635 Location: Perth, Australia
|
|
Posted: Thu Sep 27, 2018 9:36 am |
|
|
Ttelmah wrote: |
In both cases the bootloader/programming code looks for a flag in the EEPROM to perform the programming. This is only set once you have verified the code is correct. |
Another trick is to have the bootloader implement a WDT timer, enabling it when it passes control to the application. This does require the application to handle the WDT. The, if more than X WDTs occur since the application was initially bootloaded, then bootload the alternative image. For this to work, the bootloader would need to have write access to a very small part of the SPI EEPROM to store information. This technique works better if the HW implements a RTC that the bootloader can read, in this way you would count the number of WDT resets over a given time period. _________________ Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
|