Optiboot behaviour when no application loaded

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm wondering about how Optiboot works when no application is loaded.  In my testing I have observed the following strange behaviour:

 

No power cycle, Optiboot runs repeatedly:

- Power up my ATmega328PB

- Burn Optiboot to chip using ISP

- Wait a random amount of time (say, 30 seconds)

- Send `STK_GET_SYNC` message (STK500  protocol) to chip over UART

- Chip responds with `STK_OK`

 

Power cycle, Optiboot never runs:

- Power up my ATmega328PB

- Burn Optiboot to chip using ISP

- Remove power from ATmega328PB

- Restore power to ATmega328PB

- Wait a random amount of time (say, 30 seconds)

- Send `STK_GET_SYNC` message (STK500  protocol) to chip over UART

- Chip doesn't respond

 

 

Why is this?  In both cases, there is no application.  In the first case, it appears that no application = MCU resets and invokes Optiboot over and over again.   In the second case it appears that no application = MCU doesn't do anything (never resets, invoking Optiboot)

 

To get Optiboot to run repeatedly as in scenario 1 but with a power cycle as in scenario 2, would I have to modify the bootloader?

 

My issue is that I need to have the Bootloader running repeatedly whenever there is no application, so that my programmer can detect that there is a unprogrammed ATmega328PB connected to it by polling it with STK500 `STK_GET_SYNC` commands.

I love the smell of burning silicon in the morning

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From Otiboot wiki:

So it seems optiboot is "activated" by a reset, if no usart traffic, then after timeout, it jumps to app.

You either need a way to tickle the reset when you want to load new app or

modify the bootloader code to be able to detect if a valid app exists and jump or stay in bootloader mode.

 

If app is running, how do you trigger a new app load?

 

Jim

 

Click Link: Get Free Stock: Retire early!

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I took a look at that Optiboot wiki and had read all of the above before posting, however here is the part that confuses me:

 

- If I flash Optiboot and don't remove power, Optiboot appears to keep on invoking itself over and over again (I guess this suggests that Optiboot detects that there is no app and therefore doesn't ever actually run the "blank app")

- If I flash Optiboot and then power cycle the MCU, Optiboot appears to never run (I assume this means that the "blank app" is called on power-up, which does nothing (because its blank))

 

So, it would seem that Optiboot already has something built in that detects if there is an application present or not, and decides not to run the application if there is none....

 

I do have a way to tickle the reset pin when I want to upload a new app, but the issue that I'm trying to solve is how to automatically detect when a device that only has Optiboot on it is connected to my custom programmer.  Right now I am trying to accomplish this by sending STK500 codes out and seeing if anything comes back, but that only works if Optiboot is actually running (which appears to not be the case when the board is cold booted).

 

 

I love the smell of burning silicon in the morning

Last Edited: Wed. Dec 5, 2018 - 06:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In both cases, optiboot runs the app, which consists of 0xffff instructions that do essentially nothing, and it eventually wraps around the PC and starts optiboot again. In the power-on case, optiboot starts the (non-existent) app immediately (fast start). In the reset case, it starts the app after timeout of a download.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So in the power-on case, after the MCU wraps around back to the start of program memory (i.e. location of Optiboot), I guess that Optiboot fast-starts the blank app again (i.e. doesn't listen for stk500 commands on UART).

 

In the external reset case, when the MCU wraps around back to the start of program memory, it seems that Optiboot does not fast-start the app.  Why is this?  I thought that after an external reset, if no stk500 commands are received, that Optiboot should behave the same way from that point forward as the power-on case.

I love the smell of burning silicon in the morning

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Optiboot has somewhat changed the way it handles the "reset cause" in MCUSR over the years, so the exact details might depend on exactly which version you are running.  The current (github) version tries to not touch the flags, so in the EXTRF case it starts the app, the (empty) code runs until it gets to the bootloader again, where EXTRF is still set, so it does the same thing again.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaza_tom wrote:
I'm wondering about how Optiboot works when no application is loaded.

LOL -- let's start with the first statement.  How exactly does a general-purpose boot determine that the contents of application flash somehow fit the picture that you have of an "application"?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

LOL -- let's start with the first statement.  How exactly does a general-purpose boot determine that the contents of application flash somehow fit the picture that you have of an "application"?

 

Not sure what your question is.  Are you asking how Optiboot knows whether or not there is an application present in the application partition?  If so, then I think based on the insights @westfw shared above that the answer is "it doesn't".

I love the smell of burning silicon in the morning

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you can afford more flash for the bootloader then you can add a CRC check so it knows there is a whole, valid app in place before it jumps to it. In my own bootloader:
.
https://spaces.microchip.com/gf/project/sdbootloader/
.
The CRC stuff "costs" 96 bytes and it uses the standard 16 bit little endian CRC that Srecord can embed into the load image.