Is it important to erase all program memory before flashing new application from bootloader?

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

Hi,

I am on my path to write my first bootloader.

 

Q.1 One question is do you erase all the flash memory before writing? Or just enough pages which the next application will occupy? What is the norm?

Q.2 If I don't erase all the flash memory, can the left over code from the previous application interfere with the new application code in any way?

 

Out of curiosity, I tested the arduino bootloader, it seems to me that arduino bootloader does not erase all the flash memory before the next sketch upload, previous application data still lives (obviously this will only happen when the new application data size is less than the previous application data size). So this kinda answer's my question 2, if arduino is not erasing it then it must be okay. Right?

 

Note - The application for which I am writing bootloader for, the end user will be flashing new hex very frequently over USART, so for one day it might only take 5-6KB of space but for some other it might take 30KB of space. So what do I do? I am confused, bootloader should erase all the memory or just enough to get the job done?

I mean it is safer to go with "erase all the memory" but then why arduino people didn't do it? Is there any benefit to it.  

Thanks.

This topic has a solution.
Last Edited: Sat. May 1, 2021 - 12:06 PM
This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Heisen wrote:
Q.1 One question is do you erase all the flash memory before writing? Or just enough pages which the next application will occupy? What is the norm?

 

Thats up to you.  I suppose better to err on the side of caution and wipe it with all 0xFF for every location.

 

Heisen wrote:
Q.2 If I don't erase all the flash memory, can the left over code from the previous application interfere with the new application code in any way?

 

It shouldn't since properly written and compiled(assembled) code will not run into space other than what it takes.  In other words your code should only stay in its Main loop, and the functions outside of MAIN that are called and properly returned from.

 

Just my two pence.  Others with more experience than I may have a better answer

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Heisen wrote:
If I don't erase all the flash memory, can the left over code from the previous application interfere with the new application code in any way?

As Jim said, Only if there's a bug (or bugs) in your code that causes it to be accessing those flash areas.

 

But, if your code had such bugs, erasing the flash wouldn't help - your code would still be trying to execute stuff that it shouldn't.

 

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 oscillatorhttps://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...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You normally erase the whole chip before installing the Bootloader.

You set the Fuses and LockBits appropriately to prevent any writes to the Bootloader area.

 

The Bootloader normally erases a page at a time i.e. when programming a fresh page from the Application.

 

Personally,  I am happier with erasing every page in the Application area before the Bootloader programs the fresh pages.

 

This means that you can do a CRC of the whole application area.    Otherwise when the new application is small,  there are pages left over from the previous (larger) application.

 

Learning how to write a Bootloader is an interesting academic exercise.    I would prefer to use a proven design for "real life".    A Bootloader must be 100% reliable for real life use.

 

David.

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

My AVR bootloader DID erase all flash pages in the Application Section. However this was only so that I could display a reliable checksum of the Application Section flash memory.

 

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

Just some info:

unprogrammed flash don't wear the flash.

It's faster to read all bytes in a page to see if all are 0xff (on a 128 byte page size the check will only take about 32us @16MHz ) 

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

Thank you guys for the helpful suggestions. Now I understand.

 

I wasn't thinking of doing CRC or checksum because I don't know how to do it yet, but I will learn. Will make my way up to it. 

 

Right now my way of protection (which I read in some other post) forces me to erase all flash pages, which is to place a marker byte (0xAA) at the last memory location by editing the hex or bin file on PC side, and before writing, bootloader erases the marker byte first. So when the micro resets, it checks if 0xAA is placed at last memory location, if it is there it means application is intact and if it's not there then don't jump into application section.

 

sparrow2 wrote:
unprogrammed flash don't wear the flash.

 

Quick question - What happens if when we do boot_page_erase() on flash page which is already unprogrammed (all 0xFF)? Does performing this action wears the flash? I read somewhere in the forum that turning the 0's back to 1's is what causes flash wear, but in this example flash page is already all 0xFF.

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

I'd suggest reading the page first and don't event attempt a page erase if it's all 0xFF. (the read is a quick operation anyway)

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

Heisen wrote:
Quick question - What happens if when we do boot_page_erase() on flash page which is already unprogrammed (all 0xFF)? Does performing this action wears the flash? I read somewhere in the forum that turning the 0's back to 1's is what causes flash wear, but in this example flash page is already all 0xFF.

Have you told us which AVR model we are dealing with?

Tell why none of the several popular and proven bootloaders are suitable for you.  What design parameters are of utmost importance?

Tell what "flashing very frequently" means.  Let's see -- typical AVR specs are 10000 times at limits of temperature and voltage.  If we take that as the safe number, that would be once an hour every working day for five years.  That is a LOT of cut-and-try programming.

 

Heisen wrote:
I tested the arduino bootloader, it seems to me that arduino bootloader does not erase all the flash memory before the next sketch upload,...

Surely that depends on your application.  Note that it is perfectly possible and reasonable to do the total application in multiple built pieces, and to do a load to the target unit via ISP or bootloader or equivalent.  For example, there could be the "base" application that all units get, the "option modules" that are paid for, and the "config parameters" with serial number, device address, and similar.  If you are on an erasing binge, then you preclude any type of that for the life of your bootloader units.

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

Heisen wrote:
I mean it is safer to go with "erase all the memory" ...
Dead code can literally kill.

page 2 | ethics « Barr Code

[1/3 page]

Dead Code, the Law, and Unintended Consequences

...

Dead Code and the Law of Unintended Consequences | Barr Group via https://barrgroup.com/search/all/%22dead%20code%22

 

"Dare to be naïve." - Buckminster Fuller

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

awneil wrote:
your code would still be trying to execute stuff that it shouldn't.
Excessive dVCC/dt can affect the PC.

Crowbar Glitching | NewAE Technology via Education | NewAE Technology

 

"Dare to be naïve." - Buckminster Fuller

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

Heisen wrote:
... which is to place a marker byte (0xAA) at the last memory location ...
AVR instructions are 16b; NOP is zero.

Heisen wrote:
... is placed at last memory location, if it is there it means application is intact ...
"Typical" is a checksum (adequate), CRC, or a hash value; megaAVR follow-on have CRC hardware.

 


BREAK | Description | AVR® Instruction Set Manual

 

CRCSCAN - Cyclic Redundancy Check Memory Scan | Migration from the megaAVR® to AVR® Dx Microcontroller Families

 

"Dare to be naïve." - Buckminster Fuller

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

>unprogrammed flash don't wear the flash.

 

The first page of flash gets erased every time, and saving the latter pages of flash for the day when the first page no longer works only means you have some nice fresh flash that you cannot use. So flash wear would not be in my calculation for erase vs leave as-is.

 

If I was concerned about flash wear, I would probably keep the last page set aside and simply have the bootloader erase/write the last page twice leaving some useful info behind (like erase count). Any flash failure should happen to the unimportant last page long before the first page even gets close to having a problem. An advanced warning system. If there is a flash failure mode due to erase cycles that can take place after the bootloader was satisfied with its job, then it will happen to the unimportant last page first and the app will not be affected.

 

Probably the only cases when flash wear is a concern, is if using flash as eeprom type storage or if you are using a dev board and programming it dozens of times a day and using it for a long time. If the former, you will have to work out frequency so you never get 'there', the latter doesn't matter that much as it will be caught in the normal course of dev work (you are not going to re-purpose the dev board to now navigate your way to Mars). The lone mcu that has found a real job in the outside world is not going to be updated that often, maybe never, so flash wear due to erase is of little concern (and any bootloader inside is going to get bored from inactivity apart from it getting to do a little work at power on's).

 

One advantage of erase-all is someday you/someone may need to read the mcu, and looking at any leftover garbage is not going to be helpful (probably not as obvious what it is 3 years later, where erased flash will always be obvious). Even if you only erase pages in use, there is nothing stopping someone from sending erased data so can still erase all pages if wanted even if the bootloader does not normally do that. I would rather have harmless/erased flash laying around but at the same time I don't seem to be worried about all the garbage data that lives on the stack (and need not worry about even though it changes millions of times a second). The things to worry about are usually the things we don't worry about but should, and in this case the thing that is worried about need not be so either choice will be good.

 

 

 

 

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

clawson wrote:
I'd suggest reading the page first and don't event attempt a page erase if it's all 0xFF. (the read is a quick operation anyway)

Ah, got it.

theusch wrote:
Have you told us which AVR model we are dealing with?

No, it's ATmega2560 for now, using it as a prototype, in the end it will be one from the megaAVR series.

theusch wrote:
Tell why none of the several popular and proven bootloaders are suitable for you.

Ah, It's mostly because of learning purposes. I personally learn the most when I fail hard. So I hope I fail in the beginning many times. All the research afterwards regarding "why this is not working?" leads to good learning and it sticks. I find it interesting to see that after completing, watching how I wrote this and how the people have written it. Obviously I cannot be better but seeing how close was I or how off I was to the real deal is a reward for me.

 

Also if I use off the shelf bootloader and later in the game I had to change something due to end user requirement, then I will be doomed. At least if I know in's and out's of the bootloader, there will be a chance of me doing something about it, in the next revision of boards.

 

Sure with this approach I won't reach very far (it's okay) but I will certainly be better than a day before.

 

theusch wrote:
What design parameters are of utmost importance?

Fast upload speed of firmware or a part of firmware.

 

theusch wrote:
Tell what "flashing very frequently" means.

It's the animation data, which is a giant array containing each step/frame of animation with speed control for fading LEDs. Like in this video, this animation took roughly 13KB of space, it's not looped.

 

 

User creates his animations to his heart's content and hits a giant UPLOAD button on PC with easy to use GUI clickety clackety program. To see how the animations look he will be flashing repeatedly.

 

theusch wrote:
typical AVR specs are 10000 times at limits of temperature and voltage.  If we take that as the safe number, that would be once an hour every working day for five years.

 

I see, now the way you described it and curtvm's reply, flash wear is no concern.

 

gchapman wrote:

Heisen wrote:

... which is to place a marker byte (0xAA) at the last memory location ...

AVR instructions are 16b; NOP is zero.

 

Thanks gchapman for reminding, as usual with the interesting links. 

 

 

Last Edited: Sat. May 1, 2021 - 10:44 PM