| View previous topic :: View next topic |
| Author |
Message |
theteaman
Joined: 04 Aug 2006
Posts: 98
|
| upgrading the firmware functionality |
 Posted: Thu Jan 11, 2007 5:36 am |
 |
|
Hello
I have a PIC in a circuit. What I'd like to do is add functionality to it so that I can 'upgrade the firmware'. Basically I'd compile new code for the PIC, into a .hex file, and have this data sent over rs232 to the PIC which would overwrite itself with the new code. Is this possible? Is any extra circuitry needed or can I use write_program_memory?
I'm just looking to be pointed in the right direction.
Thanks |
|
 |
rwyoung
Joined: 12 Nov 2003
Posts: 563
Location: Lawrence, KS USA
|
|
| Posted: Thu Jan 11, 2007 8:38 am |
|
|
Search for this term:
bootloader
_________________
Rob Young
The Screw-Up Fairy may just visit you but he has crashed on my couch for the last month! |
|
|
theteaman
Joined: 04 Aug 2006
Posts: 98
|
|
| Posted: Thu Jan 11, 2007 7:32 pm |
|
|
Hello
Thanks. I've read up about bootloaders but I have one more question.
Is it possible to have both the loader and the actual program in the same compiled code?
What I've done is:
1. at the lowest address #ORG 0x06, placed a menu to choose between starting the loader and starting the actual program
| Code: |
#ORG 0x06, 0xCC
void main(void)
{
selection = display_menu();
if(selection = LOADER)
run_loader();
else
start_main();
}
|
2. Then I put the loader contiguously after the menu in the same segment
What I want to do is:
3. compile start_main() and all the other functions is uses at an address below the menu and loader functions. I can't see how to do this, without explicitly using #ORG on each function, which would require me calculating how much memory each function would use and this would be tedious given the code would continuously change. Is there another way?
Thanks |
|
|
theteaman
Joined: 04 Aug 2006
Posts: 98
|
|
| Posted: Fri Jan 12, 2007 4:43 pm |
|
|
| I guess its not possible then.. |
|
|
Guest
|
|
| Posted: Fri Jan 12, 2007 5:34 pm |
|
|
| What pic are u using? |
|
|
theteaman
Joined: 04 Aug 2006
Posts: 98
|
|
| Posted: Fri Jan 12, 2007 5:42 pm |
|
|
| Anonymous wrote: | | What pic are u using? |
I am using 18F2525 |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Sat Jan 13, 2007 8:25 am |
|
|
| Code: |
#ORG 0x06, 0xCC
void main(void)
{ |
On a PIC18 this address range will have conflicts with the interrupt vectors at address 0x08 and 0x018.
| Quote: | | Is it possible to have both the loader and the actual program in the same compiled code? |
Yes, this can be done. Easy. What I don't get is _why_ you want to do it like that, it is not the normal way to use a bootloader.
For your info, the normal product life cycle is:
1) Hardware is produced.
2) Program bootloader into chip.
3) Store your hardware until purchase order is received.
4) Sales department programs the required application version into chip using bootloader.
5) Ship to customer.
6) If new updates are available customer can do an update using the bootloader.
Try to see your bootloader and the main application as two completely seperate programs that are programmed into the same chip. On chip startup the bootloader is started, will do it's things and than pass on control to the second program (your real application). Funny thing is that the real application doesn't even know if it was started by a bootloader or from hardware reset (unless you implement some status flags of your own).
Now, realize that you can update the application but it is (almost) impossible to update the bootloader as the bootloader can never overwrite itself. This is why I'm not sure why you want to integrate the bootloader and the application.
Which bootloader are you using? |
|
|
drh
Joined: 12 Jul 2004
Posts: 192
Location: Hemet, California USA
|
|
| Posted: Sat Jan 13, 2007 9:39 am |
|
|
The "application" could be a factory test routine used to verify the functionality of the products inputs and outputs. Then when it is pulled "off the shelf", the latest version can be programmed in and shipped to the customer.
_________________
David |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Sat Jan 13, 2007 12:07 pm |
|
|
| drh wrote: | | The "application" could be a factory test routine used to verify the functionality of the products inputs and outputs. Then when it is pulled "off the shelf", the latest version can be programmed in and shipped to the customer. |
Yes, that's one of the possible reasons for combining a bootloader and an application into a single image file. I can think of some more reasons, but for the learning effect I like to hear from Theteaman what he goal wants to achieve. |
|
|
Guest
|
|
| Posted: Sat Jan 13, 2007 5:25 pm |
|
|
ckielstra,
You're right. Thanks, I should have them as separate programs - it will be much more logical.. My original intent was just to make it easier by having the whole file together.
I've been doing a lot of reading on bootloaders and I want to try and implement my own. If I perform the following steps:
1) the bootloader should listen to the rs232 for incoming chunks of program data sent from the pc. The first instruction has the address of the main() function and should be stored. As each chunk arrives it should use write_program_memory()
2) on reset, the loader waits 1/2 seconds for communication. If none is receieved it jumps to the main function.
Is this something that can be done without using assembly??
Thanks |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Sat Jan 13, 2007 6:15 pm |
|
|
Writing a bootloader can be done without using assembly.
Writing your own bootloader is not an easy task because of the many small hardware related 'need to know' things. |
|
|
Guest
|
|
| Posted: Sat Jan 13, 2007 6:23 pm |
|
|
| ckielstra wrote: | | Writing your own bootloader is not an easy task because of the many small hardware related 'need to know' things. |
I thought this might be the case. I guess I will continue to try to get the Colt bootloader to work (it isn't, for some reason).
Thanks for the help  |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Sat Jan 13, 2007 8:03 pm |
|
|
I think the Colt website is missing one note for the larger PIC18 chips, in the chapter on Relocating the User Code he tells you what changes to make for the #build lines, but you also have to change the #org line.
In your application file add the following code.
| Code: | #build(reset=0x800)
#build(interrupt=0x808)
#org 0x0000,0x07ff // Changed from 0x1ff to 0x7ff for 2k bootblock devices
void bootloader() {
#asm
nop
#endasm
} // Reserve space for the bootloader |
|
|
|
theteaman
Joined: 04 Aug 2006
Posts: 98
|
|
| Posted: Sun Jan 14, 2007 6:25 am |
|
|
| ckielstra wrote: | I think the Colt website is missing one note for the larger PIC18 chips, in the chapter on Relocating the User Code he tells you what changes to make for the #build lines, but you also have to change the #org line.
In your application file add the following code.
| Code: | #build(reset=0x800)
#build(interrupt=0x808)
#org 0x0000,0x07ff // Changed from 0x1ff to 0x7ff for 2k bootblock devices
void bootloader() {
#asm
nop
#endasm
} // Reserve space for the bootloader |
|
Thanks ckielstra. This is possibly a problem, but for me, Colt wont work even with the example program. Which is weird because the pc bootloader software sends the hex file ok, and it even verifies ok. I guess I will need to try jolt, but nevertheless i will also make your mentioned change to my code (once i can get the example working!).
Thanks |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
