CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

bootloader idea

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
collink



Joined: 08 Jan 2010
Posts: 137
Location: Michigan

View user's profile Send private message Visit poster's website

bootloader idea
PostPosted: Mon Jan 11, 2010 6:59 pm     Reply with quote

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

View user's profile Send private message Visit poster's website

PostPosted: Tue Jan 12, 2010 9:20 am     Reply with quote

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

View user's profile Send private message Visit poster's website

PostPosted: Tue Jan 12, 2010 9:33 am     Reply with quote

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

View user's profile Send private message Visit poster's website

PostPosted: Tue Jan 12, 2010 8:13 pm     Reply with quote

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! Razz

Rohit
mbradley



Joined: 11 Jul 2009
Posts: 118
Location: California, USA

View user's profile Send private message Visit poster's website

PostPosted: Wed Jan 13, 2010 12:31 am     Reply with quote

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: 1634
Location: Perth, Australia

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Wed Jan 13, 2010 3:33 am     Reply with quote

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

View user's profile Send private message Visit poster's website

PostPosted: Wed Jan 13, 2010 11:03 am     Reply with quote

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: 1634
Location: Perth, Australia

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Wed Jan 13, 2010 11:21 am     Reply with quote

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

View user's profile Send private message Visit poster's website

PostPosted: Wed Jan 13, 2010 12:06 pm     Reply with quote

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

View user's profile Send private message Visit poster's website

PostPosted: Wed Jan 13, 2010 12:24 pm     Reply with quote

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
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
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