| View previous topic :: View next topic |
| Author |
Message |
collink
Joined: 08 Jan 2010
Posts: 137
Location: Michigan
|
| bootloader idea |
 Posted: Mon Jan 11, 2010 6:59 pm |
 |
|
I've got a PIC18F chip that I'm writing firmware for. I'd like to support SDCard based firmware updates. I know that Brush Electronics has one. But, I do not want to take up 12K of program space for a bootloader.
So... I had an idea and I'd like to know if it's crazy or not. I was thinking of using #org to put all functions which would be in common between a bootloader and the main program into the lowest ROM addresses. Then these functions could be used to update the rest of the ROM space. The shared functions at ROM start would not be updatable via sdcard but neither is a normal bootloader. As a bonus this scheme wastes virtually no rom space for a bootloader. It's almost all shared. Could this work? |
|
 |
Rohit de Sa
Joined: 09 Nov 2007
Posts: 282
Location: India
|
|
| Posted: Tue Jan 12, 2010 9:20 am |
|
|
I can't think of a reason why it wouldn't work. However, as you already observed, keeping certain functions in the protected bootloader zone would render them un-updatable.
Most bootloaders are designed to be as compact as possible, and as such, would/should really not have any 'functions' that would be of interest to the end user. For example, the Tiny bootloader is only about 100 words big, and is written in assembly, and thus has no user 'callable' functions.
I think that trying to include user-functions into a bootloader would unnecessarily bloat the bootloader size. Such a solution may work only in a very specific, non-generic environment.
Rohit |
|
|
collink
Joined: 08 Jan 2010
Posts: 137
Location: Michigan
|
|
| Posted: Tue Jan 12, 2010 9:33 am |
|
|
| Thanks for the reply. I don't care if it would limit the bootloader to a very specific non-generic environment. It's fine with me if it's not portable. Also, as I previously mentioned, the brush electronics bootloader claims to need 12K for the bootloader. That's 12k of wasted space. Chances are that a SDCard bootloader with fat file system support would share a lot of code with the main program which also has sdcard support and fat file system support. |
|
|
Rohit de Sa
Joined: 09 Nov 2007
Posts: 282
Location: India
|
|
| Posted: Tue Jan 12, 2010 8:13 pm |
|
|
| collink wrote: | | Chances are that a SDCard bootloader with fat file system support would share a lot of code with the main program which also has sdcard support and fat file system support. |
Hmm, yes you're right. And 'sharing' code across the bootloader and main program would work in several other non-standard situations - a wireless bootloader is another example.
I don't really have much experience with FAT/SD Card interfacing, nor do I know much about the intricacies of building a bootloader - I just use 'em. Maybe some of CCS's 'big guns' can step in here! 
Rohit |
|
|
mbradley
Joined: 11 Jul 2009
Posts: 118
Location: California, USA
|
|
| Posted: Wed Jan 13, 2010 12:31 am |
|
|
Just a though, and I do this alot, why not add a second pic? the second pic sits between the main pic and the sd card? it can be used to ttl serial the application into the main pic.
Also, this could eliminate any sd code on the main pic, and use the 2nd pic as the sd driver?
just a thought.
_________________
Michael Bradley
www.mculabs.com
Open Drivers and Projects |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Wed Jan 13, 2010 3:33 am |
|
|
| collink wrote: | | Thanks for the reply. I don't care if it would limit the bootloader to a very specific non-generic environment. It's fine with me if it's not portable. Also, as I previously mentioned, the brush electronics bootloader claims to need 12K for the bootloader. That's 12k of wasted space. Chances are that a SDCard bootloader with fat file system support would share a lot of code with the main program which also has sdcard support and fat file system support. |
An SD card bootloader would not contain any write functions. It would not update directories. It could, but not necessarily implement a lite file system as there is no need to have simultaneous open files in which case it may or may not be usable for your application programs.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
collink
Joined: 08 Jan 2010
Posts: 137
Location: Michigan
|
|
| Posted: Wed Jan 13, 2010 11:03 am |
|
|
| asmallri wrote: |
An SD card bootloader would not contain any write functions. It would not update directories. It could, but not necessarily implement a lite file system as there is no need to have simultaneous open files in which case it may or may not be usable for your application programs. |
If I place all of the main program's fat file reading related functions plus the attendant sdcard routines into the bootloader segment then I can still use them from the main program. The main program can then also include the writing functions which were left out of the bootloader. This would allow me to take a 12K bootloader and share 11K of it with the main program and thus save myself 11K. The only real downside is that the 11K of shared routines will not be updatable easily. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Wed Jan 13, 2010 11:21 am |
|
|
| collink wrote: | | asmallri wrote: |
An SD card bootloader would not contain any write functions. It would not update directories. It could, but not necessarily implement a lite file system as there is no need to have simultaneous open files in which case it may or may not be usable for your application programs. |
If I place all of the main program's fat file reading related functions plus the attendant sdcard routines into the bootloader segment then I can still use them from the main program. The main program can then also include the writing functions which were left out of the bootloader. This would allow me to take a 12K bootloader and share 11K of it with the main program and thus save myself 11K. The only real downside is that the 11K of shared routines will not be updatable easily. |
It is harder to do than you think. Straight forward inabsolute assembler but difficult with the compiler. This is because the compiler and not you knows where the local and global variables are stored. You would have to complier the bootloader with the application - what value is that?
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
collink
Joined: 08 Jan 2010
Posts: 137
Location: Michigan
|
|
| Posted: Wed Jan 13, 2010 12:06 pm |
|
|
| asmallri wrote: | | collink wrote: |
If I place all of the main program's fat file reading related functions plus the attendant sdcard routines into the bootloader segment then I can still use them from the main program. The main program can then also include the writing functions which were left out of the bootloader. This would allow me to take a 12K bootloader and share 11K of it with the main program and thus save myself 11K. The only real downside is that the 11K of shared routines will not be updatable easily. |
It is harder to do than you think. Straight forward inabsolute assembler but difficult with the compiler. This is because the compiler and not you knows where the local and global variables are stored. You would have to complier the bootloader with the application - what value is that? |
Yes, the bootloader would be compiled with the application. This leaves the proper space in ram for all of the global and local variables. My goal was to use this to compile everything such that the bootloader stuff was at the high end of ROM and everything else left at the low end. They both are compiled at once and the resulting firmware image would include the bootloader too. But the bootloader would refrain from writing to it's own ROM addresses so it would only be programmed by an ICSP. As far as ROM is concerned I think that I have a workable strategy. I have three segments. The first being the main program, the second having only a shim function that calls the main program after the bootloader is done running (this to fixup the addresses of functions that could have changed since the bootloader was programmed), and a third for the bootloader.
I hadn't considered that the compiler might try to move RAM based variables but of course it could. Then the bootloader which will have not been reprogrammed in some time could stomp on the RAM space for the main program. I'm not entirely sure how easy that would be to fix... Of course, since it runs before everything else I suppose it could clobber a lot of things and not matter as the main code will just init the variables once it gains control back. The bootloader will have quit running and won't be able to step on the program once the main program has gained control.
Am I missing anything else? I appreciate the discussion as this is a very error prone type of procedure. Thanks asmallri! |
|
|
mbradley
Joined: 11 Jul 2009
Posts: 118
Location: California, USA
|
|
| Posted: Wed Jan 13, 2010 12:24 pm |
|
|
In the past, I have made a header file with the variables from any code that is already on chip.
That is, I include this in both the kernal and the main application:
int16 myVar;
#locate myVar = 0x50
if you include this in your boot loader, as well as your main application, then both app knows where myVar is located, and will not use that space for anything else
_________________
Michael Bradley
www.mculabs.com
Open Drivers and Projects |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
