Printable View
I know it may seem a bit counter-intuitive, but has anyone here had any luck embedding one of the many available bootloaders into their own application? What I'd really like to be able to do is get my own program and the bootloader taken care of in a single program step, cutting down on initial programming time. Thereafter, of course, I'd be able to update my own program over serial (no need to send the bootloader at this point).
Any pointers would be much appreciated.
Thanks,
Kevin
Mecanique Bootloader is the ONLY one i use. It comes with the full version of MicroCode Studio.
In your "mainline" code, make sure that you have it offset:
DEFINE RESET_ORG 200h ' or something appropriate
Then, you will have to just merge the two hex files together:
stripping the EOF record on the first hex file
append the second hex file
(you may want to strip out the config bits on either file, whichever is appropriate)
Now you have a single hex file with both code bases.
mister_e: Hmm . . . I've seen that one mentioned a few times here. At the risk of going a bit OT, do you happen to know if the source code for that can be licensed? I'm using RS485 rather than 232 for my main comm, so I need to add some init code for the RS485 transceiver.
dman: Wow. I had wondered if that was possible, but it sounded like too easy a solution. I guess Occam's Razor prevails!
Write your own loader in PBP.
Search the forum for bootloader, there is a post somewhere how to do it by modifying PBP in some ways, but in the end you probably have to merge the hex files if you want to program both at the same time.
and if you go for using the hardware uart it will not be that big either
/me
Jumper: After reflecting on my needs a bit more, I've come to the conclusion that writing my own bootloader would be the best option. At the very least, it'll be educational. Unfortunately, scouring the fora, I was unable to find any example code as you had suggested.
I've been looking at the TinyBld and Pikme bootloaders, so I have a pretty good idea conceptually how to proceed. I'll just have to account for ASM vs PBP. One issue I haven't been able to work out is how to handle the hex files to reprogram themselves. It looks to me that the Pikme client loads the hex file and produces a binary image that it sends to the PIC for sequential programming. Is this the norm? Or is there a more appropriate way of handling the hex file for the non-bootloader program?
Thanks,
Kevin
Search for 'MCLoader & XPort'
"MCLoader & XPort" might not be the first place to look but there is where the thread is. Read all of it because there are some misstakes in the beginning that nobody (me) cared to edit, we fixed them on the way.
Hope it helps some.... then it is "just" to send the HEX file from the PC to the PIC in any way you like, I guess the most comon way is YOP (your own protocol) using a VB program ( parse it in the same blocksize as when you program the PIC since strings are easier to fix in the PC and send the blocks for flashing)
Hope this can help, if you run into any problem let me know. It is probably not the right way of using PBP but it is quick and seems to work great. And the only way I have found to write the bootloader without skills in ASM
In this way you can even use IRDA to upgrade the application if you would like to.
/me
This still doesn't solve your first question. How to program both Bootloader and application software at the same time.
If I were you I would like to know that the serial communication part of the board works before I ship the unit or I might end up with a bootloader no one can use anyway ;-) I like my boards to enter the loader atleast once before leaving (hopefully for good)
Quality - "The customers come back, not the products"
/me
Correct. There are definitely two issues here that need to be handled.
1) I need to be able to program a bootloader and my user program in one step to keep manufacturing costs down.
2) Due to the nature of my bootloader needs, it appears that I have to roll my own.
I think I have a pretty good handle on #1 at this point. I'll be testing that out later today. #2 looks to be much more complicated than I naively assumed it would be. Anyway, time to dig my feet in a little more.
Why not just program the loader into the target, use the loader to install your
main program code, then simply read it back, save it, and use that to program
the rest?
Assuming you're not using a loader that write protects the loader firmware
region, that would give you a single .hex file to program the remaining units,
and you wouldn't need to do anything special except read back & save the
1st one.
Bruce: Thanks. That seems like a reasonable solution to problem #1. It's the writing of the actual bootloader that I'm working on now. I've found some pretty good docs on the intel hex32 format, so I think I'm just going to build a fully binary image and just dump it over serial, programming sequentially from the bootloader.