 |
 |
| View previous topic :: View next topic |
| Author |
Message |
lucasromeiro
Joined: 27 Mar 2010
Posts: 167
|
| Remote programming - OTA (HELP) |
 Posted: Tue Aug 18, 2015 10:41 pm |
 |
|
Hello guys!
I'm developing a solution and need to implement a remote firmware updating my pic!
My pic is connected to a GPRS modem that is able to receive the updating via serial.
I also have an external EEPROM 2mb that can store the new firmware for verification or if you need a buffer or reboot.
I too few things about it, the more plausible part I saw, was to use the bootloader to update the firmware stored in the EEPROM, but would have to develop a routine to replace the acquisition of data via serial to i2c which is the communication of my memory . They must be other difficulties involved. I could not leave the place .. = (
Has anyone done this?
Can anyone help me?
Thank you all
Last edited by lucasromeiro on Tue Oct 27, 2015 12:18 pm; edited 1 time in total |
|
 |
Ttelmah
Joined: 11 Mar 2010
Posts: 19553
|
|
| Posted: Wed Aug 19, 2015 1:36 am |
|
|
That called programming....
Key thing is to split the job up. Don't get hooked on the complexity of the whole thing. Instead work section by section. Get the EEPROM reads and writes working for a block, with a checksum. Then design a protocol to send the block over the modem, and verify it. Then expand this to send the area to be programmed.
You could approach the actual programming two ways. Either have a block of code at the end of the PIC's memory, which is not overwritten by the new code, which just does the job of copying the EEPROM to the main memory (a 'high memory' code-loader), and call this once the area has been sent. Big advantage, no affect on the speed of interrupts, or need to reserve an area at the bottom of memory. Downside the chip is 'toast', if power fails during the code write. Alternatively a 'bootloader', that looks at the EEPROM, for a specific flag, in a spare byte/bytes at the end, and if this is seen does the programming just like a conventional bootloader, then verifies the PIC memory, and clears the flag. This has the advantage that provided you have checked the data correctly, even if the copy to the PIC fails, it'll just repeat next time the chip powers up, until it does succeed and the verify says the code is OK.
Yes people have done similar things. However nobody is going to write it for you. There are quite a few threads here, and across the rest of the PIC-internet, about doing this type of thing. |
|
|
lucasromeiro
Joined: 27 Mar 2010
Posts: 167
|
|
| Posted: Sun Oct 25, 2015 11:53 am |
|
|
| Ttelmah wrote: | That called programming....
Key thing is to split the job up. Don't get hooked on the complexity of the whole thing. Instead work section by section. Get the EEPROM reads and writes working for a block, with a checksum. Then design a protocol to send the block over the modem, and verify it. Then expand this to send the area to be programmed.
You could approach the actual programming two ways. Either have a block of code at the end of the PIC's memory, which is not overwritten by the new code, which just does the job of copying the EEPROM to the main memory (a 'high memory' code-loader), and call this once the area has been sent. Big advantage, no affect on the speed of interrupts, or need to reserve an area at the bottom of memory. Downside the chip is 'toast', if power fails during the code write. Alternatively a 'bootloader', that looks at the EEPROM, for a specific flag, in a spare byte/bytes at the end, and if this is seen does the programming just like a conventional bootloader, then verifies the PIC memory, and clears the flag. This has the advantage that provided you have checked the data correctly, even if the copy to the PIC fails, it'll just repeat next time the chip powers up, until it does succeed and the verify says the code is OK.
Yes people have done similar things. However nobody is going to write it for you. There are quite a few threads here, and across the rest of the PIC-internet, about doing this type of thing. |
Thanks for the answer!
I've been out for a while!
I returned today.
I will start to do this code today.
I have many doubts because I have never worked with this!
I understood:
there are 2 ways: bootloader and code-loader
but I did not understand what is the best.
I do not have much experience with this.
Can you help me a little more?
I'm not asking knife that to me, but I'm asking for help.
I've never done this sort of thing.
I searched but not found anything about it. |
|
|
lucasromeiro
Joined: 27 Mar 2010
Posts: 167
|
|
| Posted: Tue Oct 27, 2015 12:16 pm |
|
|
| Can anyone help me? |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario
|
|
| Posted: Tue Oct 27, 2015 12:56 pm |
|
|
we need to see some basic stuff like what PIC you're using, specs of this EEPROM, the GPRS maodem, what development PCB you're using, your basic code like 1Hz LED program, modem driver, etc.
As MR. T points out you're not the first one who has done this BUT not many, if any, will just hand you their code. It could easily have been a thousand or two hours of their time.
Now we can help by 'tweaking' your code once we see it.
At the very least you should be able to show you can 'download' a data file from a PC, save onto the EEPROM, let the PIC read that file, modify a few bytes, and then send it back to the PC.
There is ZERO need to do it OTA (Over The Air) until you confirm, 100%, that code works via RS232 to a PC.
Jay |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Tue Oct 27, 2015 10:54 pm |
|
|
| lucasromeiro wrote: |
there are 2 ways: bootloader and code-loader
but I did not understand what is the best.
I do not have much experience with this.
Can you help me a little more?
I'm not asking knife that to me, but I'm asking for help.
I've never done this sort of thing.
I searched but not found anything about it. |
There are lots of things to consider when selecting the appropriate solution. To be clear, a bootloader and a code-loader are exactly the same thing. At some point of time, what you refer to as a code-loader must ultimately result in bootloading the PIC.
If this is for a commercial application then naturally you needs a solution which limits the probability of bricking you device in the field as a result of an interruption in the bootload process (such as loss of comms) however you also have to consider what should happen in the event of a power failure half way through either a bootload process.
Consider this - in the independent approach (your code-load approach), if you first load the image to the EEPROM, validate the image, and then bootload from the EEPROM. Then what loaded the image into the EEPROM in the first place? Was it an existing user application? If so, what happens if the user application has a bug that prevents it accepting the hex file, or initializing the I/O correctly to access the EEPROM or store it correctly in EEPROM? In these scenarios you cannot recover from a bad application image.
In the direct bootload approach the bootloader and only the bootloader is responsible for accepting the image, configuring the I/O putting the image to EEPROM (if required), validating the image, and bootloading the image. If the power fails or comms is lost during the process then the bootloader falls back to bootloader mode to continue the process.
Depending on how the bootloader is implemented you may or may not need the intermediary step in storing to the EEPROM. If you are concerned about protecting your intellectual property you will need and encrypted bootloader and the EEPROM image will need to remain encrypted with the decryption process being handled by the bootloader after reading the contents back from the EEPROM.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9246
Location: Greensville,Ontario
|
|
| Posted: Thu Oct 29, 2015 4:30 pm |
|
|
couple of comments.
1) power failure should not be possible. A properly designed battery backed power supply will not allow failure. This means using BIG batteries, testing/monitoring them for proper charge and capacity, etc.
2)When the 'uploading/updating ' process has begun, an independent timer should be started. Should the upload not be completed in say xxx seconds, then the process is aborted, PIC resumes original program. Perhaps maybe try the upload 2 or 3 times, then flag as 'upload aborted'.
Jay |
|
|
lucasromeiro
Joined: 27 Mar 2010
Posts: 167
|
|
| Posted: Mon Nov 09, 2015 8:16 pm |
|
|
looking at the libraries available in the CCS, which has seen:
bootloader.h
loader.c
It has also three examples:
ex_load.c
ex_bootload.c
ex_bootloader.c
I will use this, right?
but I still do not understand the difference of bootloader.h to loader.c.
which should I use?
now I found these examples and libraries, it became easier! I had not seen before!
I'm thinking of doing so. correct me if I'm wrong.
1- use bootloader.h along with loader.c, like the example EX_BOOTLOADER.c. but instead of reading has some pin up, I read a flag in EEPROM to know if I should upgrade.
2- I get the code through the gprs, record in EEPROM I signal and the updating of flag. then restart the pic.
3-'ll read that need updating and I will load the data in the EEPROM memory of the pic using loader.c. but I have to make modifications for him to accept the reading of the EEPROM.
4- mute flag of memory to record and reset the pic.
Am I right?
I just need to understand two things.
1- how to write the EEPROM data received. is each character in a memory space?
2- changing the loader.c to read the external EEPROM.
I forgot something? |
|
|
lucasromeiro
Joined: 27 Mar 2010
Posts: 167
|
|
| Posted: Wed Nov 11, 2015 8:48 pm |
|
|
| Can anyone help me? |
|
|
wangine
Joined: 07 Jul 2009
Posts: 98
Location: Curtea de Arges, Romania
|
|
| Posted: Thu Nov 12, 2015 11:27 am |
|
|
| lucasromeiro wrote: | | Can anyone help me? |
In simple terms, post your code and I'm sure , you will receive 1 million explanations, but..... be sure no one will write the code for you. HELP is meant to anyone help you when your functions don't work like you expect, or some knowledge is missing, or a simple bug, but without a base to start i don't know how someone can help you. |
|
|
lucasromeiro
Joined: 27 Mar 2010
Posts: 167
|
|
| Posted: Thu Nov 12, 2015 1:55 pm |
|
|
| wangine wrote: | | lucasromeiro wrote: | | Can anyone help me? |
In simple terms, post your code and I'm sure , you will receive 1 million explanations, but..... be sure no one will write the code for you. HELP is meant to anyone help you when your functions don't work like you expect, or some knowledge is missing, or a simple bug, but without a base to start i don't know how someone can help you. |
I do not want anyone give nothing to me.
I just want to understand.
I posted up a few things, but I'm not sure if what I said is the correct path.
I have no code yet, because I do not know if this is the path we have to follow.
I need exactly that, a basis to begin.
People explained to me the theory, I understood. But now I'm leaving for the practice and wrote down what I'm wanting to do, but no-one answered me if I'm right or not. understood? |
|
|
wangine
Joined: 07 Jul 2009
Posts: 98
Location: Curtea de Arges, Romania
|
|
| Posted: Thu Nov 12, 2015 2:11 pm |
|
|
| Ok ok , in that case you get already ALL the anwers you ask , Ttelmah , temtronic and asmallri give you already the good advice how to start . Good luck and... don't fogged to share with as your progress . |
|
|
lucasromeiro
Joined: 27 Mar 2010
Posts: 167
|
|
| Posted: Thu Nov 12, 2015 2:14 pm |
|
|
| wangine wrote: | | Ok ok , in that case you get already ALL the anwers you ask , Ttelmah , temtronic and asmallri give you already the good advice how to start . Good luck and... don't fogged to share with as your progress . |
thank you!
I'm hoping someone tell me if I'm on the right track:
Looking at the libraries available in the CCS, which has seen:
bootloader.h
loader.c
It has also three examples:
ex_load.c
ex_bootload.c
ex_bootloader.c
I will use this, right?
but I still do not understand the difference of bootloader.h to loader.c.
which should I use?
now I found these examples and libraries, it became easier! I had not seen before!
I'm thinking of doing so. correct me if I'm wrong.
1- use bootloader.h along with loader.c, like the example EX_BOOTLOADER.c. but instead of reading has some pin up, I read a flag in EEPROM to know if I should upgrade.
2- I get the code through the gprs, record in EEPROM I signal and the updating of flag. then restart the pic.
3-'ll read that need updating and I will load the data in the EEPROM memory of the pic using loader.c. but I have to make modifications for him to accept the reading of the EEPROM.
4- mute flag of memory to record and reset the pic.
Am I right?
I just need to understand two things.
1- how to write the EEPROM data received. is each character in a memory space?
2- changing the loader.c to read the external EEPROM.
I forgot something? |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
