| View previous topic :: View next topic |
| Author |
Message |
hmmpic
Joined: 09 Mar 2010
Posts: 314
Location: Denmark
|
| PIC Firmware update? |
 Posted: Sat Oct 17, 2015 5:03 am |
 |
|
Firmware update:
I have a full working project with a GSM/GPRS module and a PIC18, I need some way to make firmware update. I think a way can be to get the "file" over GPRS and store the file on a SD or other low cost ram. After complete download to the SD make a CRC check, and set a bit in EE, the bit indicate a new update file is ready and CRC is ok.
Now I cant find the right way to make the next step. One way can be with a bootloader looking for the EE bit, and then making an firmware update and after clear the EE bit. What other way is there?
I need a simple and code effective way. |
|
 |
temtronic
Joined: 01 Jul 2010
Posts: 9197
Location: Greensville,Ontario
|
|
| Posted: Sat Oct 17, 2015 5:51 am |
|
|
If your program is less than 1/2 the size of EEPROM,could you not load the new program into 'top half' of EEPROM then tell the PIC to reboot and use the 'top' program instead of the old or 'bottom' program?
I'm thinking that PC BIOS 'updates' must operate in this fashion,where the original WORKING code is available in case the 'update' version didn't copy correctly.
I did something similar in the old COCO computer days, 32KB for program 'A', 32KB for program 'B' and would select which was to be the 'real' program.
Jay |
|
|
hmmpic
Joined: 09 Mar 2010
Posts: 314
Location: Denmark
|
|
| Posted: Sat Oct 17, 2015 7:44 am |
|
|
| I use about 70% of a PIC18F26K22 so not possible in my case. |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9197
Location: Greensville,Ontario
|
|
| Posted: Sat Oct 17, 2015 8:32 am |
|
|
hmm any chance you can add an external EEPROM that could hold 2 copies of your software? That way you could update 1, keep the current version in the other 1/2.
Updating would involve
1) copying current PIC EEPROM to external
2) uploading new version to external EEPROM
3) copying new version from external EEPROM to PIC
I know a bit of a 'housekeeping' chore but it would allow the current version to be saved in case of a 'problem'.
Jay |
|
|
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Sat Oct 17, 2015 9:39 am |
|
|
Please let me know if you get this to work.
I'd like to do the same.
I am about to deploy 16 modules with PIC18, WiFi (ESP8266) and GPRS(Telit) backup.
G.
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
ezflyr
Joined: 25 Oct 2010
Posts: 1019
Location: Tewksbury, MA
|
|
| Posted: Sat Oct 17, 2015 2:16 pm |
|
|
Hi,
Unless you can be assured of a reasonably robust firmware transfer mechanism (radio, cellular, ethernet, USB, serial, SD card, etc.), I would suggest that you really should not be considering remote firmware updates in the first place!
Once the above is assured, all you really need is a good bootloader that has been optimized for the firmware transfer mechanism, and written in such a way that the loader itself is protected.
_________________
John
If it's worth doing, it's worth doing in real hardware! |
|
|
hmmpic
Joined: 09 Mar 2010
Posts: 314
Location: Denmark
|
|
| Posted: Sat Oct 17, 2015 2:50 pm |
|
|
Yes I know it must be written nice.
Is there any commercial code for sale there can do it?
I can handle to get the fw file loaded to the SD chip and check it is 100%, but the bootloader code is not for me. There are too many things there can go wrong, therefore a well tested and working loader is what I looking for.
--Can it be done without a bootloader, and if how? |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1904
|
|
| Posted: Sat Oct 17, 2015 4:37 pm |
|
|
I'm not sure if this person sells what you're looking for (exactly), but I'm sure they sell something similar that might be modified to suit your needs. Have a look at http://brushelectronics.com
Not affiliated, just a very satisfied customer of his SD card driver. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Sat Oct 17, 2015 8:53 pm |
|
|
| newguy wrote: | I'm not sure if this person sells what you're looking for (exactly), but I'm sure they sell something similar that might be modified to suit your needs. Have a look at http://brushelectronics.com
Not affiliated, just a very satisfied customer of his SD card driver. |
There are a few issues to consider. There are multiple ways to deal with bootloading a new image and here are two examples: You can use a two stage code upgrade (bootload) or a single stage approach. In the two stage approach the new image or hex file is loaded by the user application into some secondary storage. The user application checks for validity of the image, sets some flags, and passes control to the bootloader (usually by resetting the PIC). The bootloader checks the state of the "bootloader new image" flag as well as other bootloader status flags and performs the bootload process.
A couple of disadvantages with this approach are:
If a bug was inadvertently introduced in the application, it may not be possible to perform the bootload process and potentially an errant user application would brick the device.
Both the bootloader and the application must know how to access the secondary storage device. The application to store the new image and the bootloader to read the image. If you were to use a SD card and what to use a FAT file system on top, it means the bootloader and the application must contain the file system code. This code would be too large to fit on hmmpic's processor. You might ask, why? - Can't I share the code between the application and the bootloader? The reason you don't share the code is because you have now created a dependency between the application and the bootloader - tying them to the same libraries, compiler versions, toolchains etc. In hmmpic's case he could use low level functions to write to predefined sectors on the SD card (not use a file system). The would enable a much smaller code footprint to be used at the expense of read/write compatibility with third party devices.
The single stage approach has the bootloader putting the new image directly on top of the existing application image. But what happens if power fails during the bootload process and the application user space contains an invalid image? The single stage bootloader, through the use of flags, knows when the user application space does not contain a user image and in this event remains in bootloader mode. The bootloader must contain enough logic to enable a connection to the bootloader to be established. In Gabriel's case, the network stack is offloaded to the ESP8266. This makes it relatively easy to implement a reliable bootloader of this type.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Sun Oct 18, 2015 1:10 pm |
|
|
Ive always thought of doing this using a smaller PIC to act as a programmer driving PCD and PGC like if it where a local Pickit...
... just a idea.
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19433
|
|
| Posted: Sun Oct 18, 2015 3:04 pm |
|
|
| That approach has the big advantage that _it_ can be the chip that reads the data, talks to the EEPROM, and does the actual programming. No space needed in the main chip for the 'bootloader', and since it is independant of the code written, you can try again if the main chip does fail to work after the load. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1634
Location: Perth, Australia
|
|
| Posted: Sun Oct 18, 2015 8:04 pm |
|
|
| Ttelmah wrote: | | That approach has the big advantage that _it_ can be the chip that reads the data, talks to the EEPROM, and does the actual programming. No space needed in the main chip for the 'bootloader', and since it is independant of the code written, you can try again if the main chip does fail to work after the load. |
If the solution is for educational, hobbyist or applications where there is no requirement to protect intellectual property then this can be a very effective approach. You naturally have to deal with how to get the image to the programming device in the first instance. If it requires a correctly performing application image then you can potentially still end up with a brick.
If the solution is for a commercial product that requires protection of the intellectual property, then this solution is no good because it uses the standard ICSP interface to the target PIC which fully exposes the contents of the PIC during the programming process. In this scenario an encrypted bootloader is a better option.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
