Calling bootloader functions from user application

malfieri9 · ‎2009-03-04

Posted on March 05, 2009 at 06:25

trevor1 · ‎2011-05-17

Posted on May 17, 2011 at 12:56

Hi m.alfieri,

Maybe this is a silly question but do you really need to do this? Are you that stuck for code space that you can't just include the functions you need in your application as well as in your bootloader?

Calling functions in the bootloader from the app, as well as not being easy, leads to many computability issues and will be difficult to manage whn your product is rolled out. I guess you don't plan to change your bootloader once it is working (which is always the plan but never seems to work out like that) but if you did it would not be easy.

I suspect you do have a good reason to do this so I guess I'm just curious what it is.

Regards

Trevor

jj · ‎2011-05-17

Posted on May 17, 2011 at 12:56

Very interesting...

Agree with last poster ''trevor'' who has requested that you better ''sell'' your info request to this forum. If more viewers could understand the benefits you're after believe that you'd get more - and possibly more in-depth - response. Good luck.

malfieri9 · ‎2011-05-17

Posted on May 17, 2011 at 12:56

I'm using UARTs for communication with peripherals embedded into my board and i just have USB as diagnostic port. So the idea is to use a virtual com, but since this implies some KBs of code i would like not to duplicate it.

Indeed, i must save a copy of the application in a serial flash using SPI, so also this code should be written twice..

Finally, also the flash routines are useful in the application.

And in general i thought it should be always better not to duplicate code..

I'm now realizing this is difficult; of course if it will be impossible i will include code twice, but i hope that someone out there knows how to do it in a better way!

One more reason: i would like to know how to do it even just to learn something new.

:-)

j2 · ‎2011-05-17

Posted on May 17, 2011 at 12:56

Hi,

what is ''MSP'' ?

jerome

edit: the Main Stack Pointer ....

[ This message was edited by: j.vaquie on 05-03-2009 14:34 ]

jwormsley2 · ‎2011-05-17

Posted on May 17, 2011 at 12:56

I can see a use for such a thing, where the bootloader, beyond just being a bootloader, could also be a BIOS of sorts. It could even be useful to define various functions there, such as display output, that were custom to the hardware, and have a single application that could run on different boards by using the BIOS calls. This is an approach that I'm considering, more to handle different board revisions which may move I/O lines or changing CPUs (such as from a 48 pin to 64 pin) where the peripherals are located on different GPIOs.

trevor1 · ‎2011-05-17

Posted on May 17, 2011 at 12:56

It is very interesting to see all the different approaches to this.

I have almost the opposite approach. I have a common bootloader (very small) that runs on several different boards.

I have as little functionality as possible in the bootloader so that I can update 99% of the code i.e. the application code (e.g. over GPRS or Ethernet). I don't want to be in a situation where I'm saying ''I can't update that code because it lives in the bootloader''.

I do make it possible to overwrite the bootloader from the application but this is a risky operation as loosing power while writing the bootloader would be unrecoverable remotely. Therefore I never do this -- it's only there as a last resort.

Also the bigger the bootloader the greater the chance of it containing a bug that you can't update remotely.

I realise others do it differently because they have different requirements of a bootloader. I just thought I'd share my reasons for the way I do it.

Regards

Trevor