Bootloader RAM Usage

Log in or register to post comments
Go To Last Post
14 posts / 0 new
Author
Message
MalphasWats
MalphasWats's picture
Level: Hangaround
Joined: Mon. Apr 30, 2018
Posts: 150 View posts
#1
Posted by MalphasWats: Tue. Dec 10, 2019 - 09:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

 

  Continuing my exploration of building a bootloader, I realise that my understanding of how RAM is managed is still a bit off. (Warning, probably a stupid question - they're my main area of expertise).

 

My intention is to write a really simple BL that will read an image from an SD card and write that into the flash of my MCU (eventually my second favourite one - ATmega1284P, but currently a 328 (4th favourite) for testing).

 

Both controllers have enough RAM to suck down a whole page from the SD card at a time, so no reason not to. Once I JMP to the freshly programmed firmware, presumably that chunk of RAM is now full of 'garbage'.

 

Is it enough to use malloc() and free() in my bootloader to allocate the read buffer to ensure that the RAM is then freed? Does the 'main' program even care that the bootloader allocated some RAM? I wasn't sure what actually tracks it all!

 

-Mike

Tags:

Tools, Compilers and General Programming
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101079 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Dec 10, 2019 - 10:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MalphasWats wrote:
a really simple BL that will read an image from an SD card and write that into the flash
Like my one perhaps?...

 

https://github.com/wrightflyer/sdbootloader

 

MalphasWats wrote:
Once I JMP to the freshly programmed firmware, presumably that chunk of RAM is now full of 'garbage'.
How is that actually any different to when you normally first apply power to an AVR anyway (whether a bootloader runs or not). The "app" that you start to execute knows nothing about what has happened before its entry point is called. That is why all C programs (and sensible Asm programs) initiallise all RAM that they will then go on to use.

 

What's more you can even "CALL" the app because this may well PUSH the return address after the CALL but, again, the very first thing the app will likely do is to reset the stack pointer so any "rubbish" you just pushed onto the stack is orphaned anyway.

 

MalphasWats wrote:
Is it enough to use malloc() and free() in my bootloader to allocate the read buffer to ensure that the RAM is then freed? Does the 'main' program even care that the bootloader allocated some RAM?
As such this question is irrelevant. You can do what you like with the RAM in your bootloader because, when the app starts, it starts with a "clean sheet" (well actually a "bit dirty sheet") anyway.

 

The ONE place where all this may be an issue is if you start to share routines out of your bootloader for use by the app code. The bootloader and the app are built as two entirely unconnected programs. When the bootloader is built the linker will map out a certain usage for its variables in RAM (not autos/locals, just statics and globals). The app will have it's own layout. If you now share a routine out of the bootloader code then if, during the execution of that function, it makes any assumptions about where anything is in RAM (i.e. it accesses statics or globals) then it's "layout" for RAM will be the wrong one when it is called from the app code (which has a different layout).

 

As such, make everything that is shared RE-ENTRANT so it has no dependence on fixed location statics or globals. If there is some reason it MUST use fixed locations you are going to have to go through hoops to (a) persuade the bootloader to build with such locations in some "protected" area (probably above the stack) and (b) to make sure the app is also built so as to not sue the protected area.

 

Easy answer, make everything re-entrant!! ;-)

Top
MalphasWats
MalphasWats's picture
Level: Hangaround
Joined: Mon. Apr 30, 2018
Posts: 150 View posts
Posted by MalphasWats: Tue. Dec 10, 2019 - 11:01 AM (Reply to #2)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you, that's what I'd hoped was going on!

 

Any 'shared' code should be pretty straightforward - I envisioned the bootloader giving some basic feedback via an OLED screen, which would require a font and some code for writing characters etc and thought it might be nice to only need 1 copy of that so it all should be stateless almost macros.

 

Thanks for sharing yours - I'm at the stage-of-even-more-laziness in the hope I can get away without needing a filesystem, just reading blocks of bytes. I think I should be able to write program .hex files as disk 'images'. Definitely helpful to see a proper one!

 

It's a hobby project, mostly for learning and the hope of some fun, so it doesn't need to be terribly robust :)

 

Thank you

-Mike

Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101079 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Tue. Dec 10, 2019 - 11:38 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MalphasWats wrote:
I envisioned the bootloader giving some basic feedback via an OLED screen,
You appear to be over engineering! There's only one main rule for bootloader code and that is "it must be 100% fault free on day one". Everything else the device does can be fixed/replaced by a bootloader update but the bootloader itself cannot be fixed, so it MUST work. The way you make it fault free is to keep it as simple as you possibly can. You don't throw "eye candy" at it like OLEd displays and so on. Bootloading is something the user does once every 6..12 months for about 10 seconds. If they need to be "entertained" during those short periods flash an LED at them or something.

 

MalphasWats wrote:
I think I should be able to write program .hex files as disk 'images'.
If you have an OS that just lets the entire disk image of 512 byte sectors be opened as a "file" then, yes, this is doable. Linux obviously makes something like this very easy. It's more complex to do this kind of thing in Windows.

Top
MalphasWats
MalphasWats's picture
Level: Hangaround
Joined: Mon. Apr 30, 2018
Posts: 150 View posts
Posted by MalphasWats: Tue. Dec 10, 2019 - 11:52 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

You appear to be over engineering! ...

...Bootloading is something the user does once every 6..12 months for about 10 seconds. If they need to be "entertained" during those short periods flash an LED at them or something.

 

Definitely over engineering, and you're absolutely right of course! I've been working on a gaming device project for some time now and this is the next iteration of that - I want to put different games on 'cartridges' that can be swapped - the bootloader will be more like a simple Operating System which allows new games to be flashed onto the MCU, so I want it to look a bit fancier.

 

clawson wrote:

MalphasWats wrote:
I think I should be able to write program .hex files as disk 'images'.
If you have an OS that just lets the entire disk image of 512 byte sectors be opened as a "file" then, yes, this is doable. Linux obviously makes something like this very easy. It's more complex to do this kind of thing in Windows.

 

I've just been reading about that - I mostly use Linux these days, so hopefully won't be too much of a problem, although to be fair, FAT16 & 32 appear to be fairly simple to work with, so I might just have a go for the learnins.

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

When you open the card open it as /dev/sdX not /dev/sdXN for example /dev/sde not /dev/sde1 or something. That way you hit the entire card right from sector 0. Also to make sure it's the right /dev/sdX use "sudo fdisk -l" to get a list of all drives. Look for the capacity you know the card to have to identify it.

Top
Krupski
Krupski's picture
Level: Hangaround
Joined: Tue. Nov 17, 2015
Posts: 219 View posts
Location: NY, USA
Posted by Krupski: Fri. Dec 13, 2019 - 07:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
If they need to be "entertained" during those short periods flash an LED at them or something.

Flashing bootloader LEDS are absolutely awful. It basically removes that pin from being able to be used (unless the user doesn't mind his motor "blinking" on and off... or if the exploding bridgewire firing circuit is connected to pin13...)

Gentlemen may prefer Blondes, but Real Men prefer Redheads!

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

So buy an AVR with more pins?!?

Top
MalphasWats
MalphasWats's picture
Level: Hangaround
Joined: Mon. Apr 30, 2018
Posts: 150 View posts
Posted by MalphasWats: Fri. Dec 13, 2019 - 09:27 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

So buy an AVR with more pins?!?

 

Too easy! ATTiny85 FOR ALL TEH THINGS! Put a Piezo speaker on MISO and it sings too!

Top
awneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 21327 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Fri. Dec 13, 2019 - 09:35 AM (Reply to #7)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Krupski wrote:
Flashing bootloader LEDS are absolutely awful. It basically removes that pin from being able to be used...

But remember that the LED was clawson's alternative to the OP's idea of using an OLED !!

 

surprise

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Top
MalphasWats
MalphasWats's picture
Level: Hangaround
Joined: Mon. Apr 30, 2018
Posts: 150 View posts
Posted by MalphasWats: Fri. Dec 13, 2019 - 11:41 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

But remember that the LED was clawson's alternative to the OP's idea of using an OLED !!

 

surprise

 

Yep, and I'm still gonna use one, so ner wink it's gonna have a little progress bar and everything*. Since my device ALSO has LEDs on it, I might just flash those too.

 

My target is the beefy ATMega1284P, plenty of pins - I'm even using the 8-bit parallel data bus on the OLED controller instead of SPI.

 

*TBD

 

 

Top
awneil
awneil's picture
Level: 10k+ Postman
Joined: Fri. Jul 1, 2005
Posts: 21327 View posts
Location: Basingstoke, Hampshire, UK
Posted by awneil: Fri. Dec 13, 2019 - 12:08 PM (Reply to #11)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just remember what clawson said in #4 on the implications of that ...

 

EDIT

 

I guess you could mitigate that with some sort of 2-stage loader:

  1. load the bit that does the OLED stuff;
  2. that then loads the full app ...

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillator: https://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. Dec 13, 2019 - 12:10 PM
Top
MalphasWats
MalphasWats's picture
Level: Hangaround
Joined: Mon. Apr 30, 2018
Posts: 150 View posts
Posted by MalphasWats: Fri. Dec 13, 2019 - 12:20 PM (Reply to #12)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's not a bad idea.

 

My bootloader just gained a pong implementation you can play whilst you wait for it to flash the code cheeky

Top
joeymorin
joeymorin's picture
Level: 10k+ Postman
Joined: Tue. Jul 17, 2012
Posts: 12051 View posts
Location: Location, Location
Posted by joeymorin: Fri. Dec 13, 2019 - 04:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

MalphasWats wrote:
My intention is to write a really simple BL

MalphasWats wrote:
I envisioned the bootloader giving some basic feedback via an OLED screen

MalphasWats wrote:
My bootloader just gained a pong implementation you can play whilst you wait for it to flash the code

If you say so.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Top