having bootloader but not starting through it

Log in or register to post comments
Go To Last Post
9 posts / 0 new
Author
Message
meslomp
meslomp's picture
Level: Raving Lunatic
Joined: Wed. May 2, 2007
Posts: 6367 View posts
Location: Nieuwegein, Netherlands
#1
Posted by meslomp: Thu. Apr 12, 2018 - 06:44 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a strange idea, but have totally no experience with bootloaders so wonder if it can be done at all.

I want to develop a datalogger that I can use to track were we have been while walking.

why: as a learning experience. So I do know I can just go to a chineese online store and buy zillion for 1/100th of the price my logger will cost, but I want to be using it as learning platform for myself.

 

Now I am going to put the whole thing in a box and only a mmc card slot and a USB connection will be accessible in the end. 

As I want to keep the USB connection for debugging I would like to go the route of using the MMC card to update FW when needed.

I know Cliff has made a bootloader that can do that, so after I found that code that should be covered.

 

Now I am wondering if it is possible to have a bootloader present, but not starting through the bootloader at start-up of the processor.

So my idea is to have the processor start the normal user application and when the operator (I have LCD + keyboard) selects a programming option, the bootloader is started and then most likely starts reading the mmc to see if a valid hex is avaliable.

 

I think that involves not setting the bootrst fuse such that the bootloader is not activated at start-up and most likely also means I still have to set the section size to the correct one as to be able to have the SPM operation available. But I am wondering if this is possible at all.

another route could be that the bootloader will check a fixed location in the eeprom at start-up and if that does not hold a special character it will switch to user mode, but then I have to figure out how to make sure that that specific location is fixed defined as I will be storing more parameters in the eeprom and till now not have done anything other than just a struct that just has the names and the compiler can do with it what it wants.

 

So I hope someone can shed a bit of light on this as this is way beyond uncharted territory for me.

 

Tags:

Tools, Compilers and General Programming
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101577 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Thu. Apr 12, 2018 - 09:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meslomp wrote:
Now I am wondering if it is possible to have a bootloader present, but not starting through the bootloader at start-up of the processor.
Why would you do it like that? If you used my SD bootloader then, sure, when it starts it has to wait for the card to init then I guess it probably reads something like 4 sectors before it realises that the code it has (number held in EEPROM) is at least as late as any file on the card but all that is probably over in a 100ms or less. Does that "delay" at power on really matter?

Top
MarekJ71
MarekJ71's picture
Level: Hangaround
Joined: Thu. Jan 19, 2012
Posts: 101 View posts
Location: Czestochowa, Poland
Posted by MarekJ71: Thu. Apr 12, 2018 - 11:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is possible, but it is not recommended. Since correctly working application is required to run the bootloader, you won't be able to run the bootloader if there is something wrong with the application, i.e. it works incorrectly for any reason or there was an issue during flashing.

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101577 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Thu. Apr 12, 2018 - 12:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MarekJ71 wrote:
you won't be able to run the bootloader if there is something wrong with the application
Exactly that - the bootloader should always run and it must not be in any way dependent on anything in the app. Consider the scenario where an app rewrite is part way through and there is a catastrophic power failure. At next power on can the system fully recover? If not you have built a time bomb!

Top
bitflipser
bitflipser's picture
Level: Wannabe
Joined: Tue. Apr 3, 2018
Posts: 60 View posts
Posted by bitflipser: Thu. Apr 12, 2018 - 01:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Isn't Optiboot directly jumping to the application program, if it was not an 'external reset'? On 'power on reset' it should jump to the application without blinking and waiting ...

 

 

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101577 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Thu. Apr 12, 2018 - 01:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bitflipser wrote:
Isn't Optiboot directly jumping to the application program, if it was not an 'external reset'? On 'power on reset' it should jump to the application without blinking and waiting ...
Oh sure a bootloader can choose to just pass straight into the app if it's not PORF or no "trigger" is seen (trigger can be received data on UART, SPI, TWI etc or it might be an input held high/low or a value found in an EEPROM location or something else you can think of) but the point is that the bootloader MUST be given the chance to run if it thinks it needs to first. It can't rely on execution going straight to the app (0) and the app making some decision for "I must bootload now" because one day that app code might be missing / corrupt. (actually if it were totally missing the fact that 0xFFFF executes as SBRS R31, 7 means that execution would eventually hit the bootloader anyway)

Top
meslomp
meslomp's picture
Level: Raving Lunatic
Joined: Wed. May 2, 2007
Posts: 6367 View posts
Location: Nieuwegein, Netherlands
Posted by meslomp: Fri. Apr 13, 2018 - 05:59 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok, thanks for the insight...

I indeed have not thought about what could happen in the case of application failure.

the power on time is critical as I have to set a certain IO line to a output high level in a very short time frame to keep the power supply ON.

After that it is of less importance that the bootloader takes some time.

Writing this I guess that a bootloader can do a GPIO init before actually starting as that is only a couple of instructions.

 

 

with the remarks above a second question has arisen....

as it is stated that the bootloader uses eeprom and also my code will be using the eeprom, how are you going to keep those separated?

will the bootloader always be part of the project to ensure that the compiler and linker do not put application "things" in the areas bootloader uses?

I would like to stick with AS and its makefile process as that saves me a number of potential headaches.

 

 

 

Top
MarekJ71
MarekJ71's picture
Level: Hangaround
Joined: Thu. Jan 19, 2012
Posts: 101 View posts
Location: Czestochowa, Poland
Posted by MarekJ71: Fri. Apr 13, 2018 - 07:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meslomp wrote:

the power on time is critical as I have to set a certain IO line to a output high level in a very short time frame to keep the power supply ON.

After that it is of less importance that the bootloader takes some time.

Writing this I guess that a bootloader can do a GPIO init before actually starting as that is only a couple of instructions.

The bootloader can and should set IO lines to their required states.

 

meslomp wrote:
will the bootloader always be part of the project to ensure that the compiler and linker do not put application "things" in the areas bootloader uses?

You are actually going to create two separate applications, so there should be two projects. You should set linker options (i.e. configure sections) to use separate FLASH areas - application area for the application and bootloader area for the bootloader. The details depend on MCU - as far as I can rememeber, for Xmega you don't need to change anything for the application project since by default bootloader area is not used.

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101577 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Apr 13, 2018 - 08:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meslomp wrote:
as it is stated that the bootloader uses eeprom and also my code will be using the eeprom, how are you going to keep those separated?
I deliberately wrote it to use the very last 2 byes in EEPROM to keep the 16 bit version number so that is "well out of the way" of the applications own EEPROM usage. If, for some reason the EEPROM has to be completely wiped at any stage (so last two bytes are 0xFFFF) then the value 0xFFFF is the marker I use in that location to say "there is no valid app loaded, time to re-flash at next power on". So it should not matter.

 

For details see line 145 here:

 

https://spaces.microchip.com/gf/...

 

that basically says:

// Currently loaded application code version is held in EEPROM (or 0xFFFF if nothing there
// or a previous update was interrupted)
flashver = eeprom_read_word((const uint16_t *)E2END - 1);

 

Last Edited: Fri. Apr 13, 2018 - 08:30 AM
Top