how to safely transmit MCUSR contents from bootloader to main program?

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

 

The AVR libc docs show how to safely get MCUSR copied into a variable and reset early (as required to prevent possible infinite resets) in the top of this page:

 

    http://www.nongnu.org/avr-libc/u...

 

What I'm wondering is how to safely transmit the mcusr_mirror variable discussed there from the bootloader to the main application program.  I'm building both programs from C.  I think it should be possible to put the contents in a high memory byte or perhaps a register.  Somewhere that is safe from the compiler anyway.  But where?

 

I guess this is really a general question about how to transmit a bit of stuff from bootloader to main program, when both are in C, without having to resort to EEPROM.  It might be a good idem for the bootloader faq.

 

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

A predetermined location  in EEROM?

 

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Perhaps an unitialized (by the app program) global variable?

 

277,232,917 -1 The largest known Mersenne Prime

Measure twice, cry, go back to the hardware store

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

ka7ehk wrote:

A predetermined location  in EEROM?

 

Jim

 

That would be a slam dunk, but I'd like to avoid doing it with eeprom if possible.  It seems like if I knew gcc conventions there would almost certainly be a safe chunk of ram (the end?) or a register or something.  At least assuming that it gets read out early from the main program some memory should be safe that long.

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

Torby wrote:

Perhaps an unitialized (by the app program) global variable?

 

Then how do you determine where this global is put by the build of the bootloader program, and sync it up?  I'm trying to follow the approach in the bootloader_faq.pdf where they're separate programs with separate builds.  If there are gcc attributes to lock a variable to a particular address that's great I guess.

 

Looking a little more I find

 

   http://stackoverflow.com/questio...

 

which suggest it can be done safely with one linker option, and no need for a linker script.  I'm still not clear how safe it is though.

 

I guess all such tricks assume malloc() or something doesn't come along and stomp on it but I guess for mcusr_mirror it can be required to be read out pre-malloc() (for uc programs ambitious/crazy enough to use that).

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

The bootloader can put it in R1.

The app, in section .init0 can STS R1 to a variable in the .noinit section.

"For every Christmas tree lit before Thanksgiving,
an elf drowns a baby reindeer"

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

if the CPU has GPIORx registers, they are a good place for something like this.

Mike Adams
ADI Development, Inc.
http://www.adidev.com

... When it has to actually work.

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

Unless it is a very old AVR why wouldn't you simply use the GPIOR0 / GPIOR1 / GPIOR2 provided for this (and other) purposes? If it is an old one use something like TWAR.

EDIT : sorry, I missed dr.mike's reply on this phone so I guess we agree ;-)

Last Edited: Fri. May 5, 2017 - 10:37 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bkerin wrote:
That would be a slam dunk, but I'd like to avoid doing it with eeprom if possible.

I'll bite -- if all [?] AVR8 models have EEPROM and if you can spare enough bytes, then why is the use being dismissed out-of-hand?  Once written, it will survive unexpected power loss or other reset.

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

Expecting >100,000 power cycles perhaps? (devil's advocate)