Filling flash with 0xFF

[sanka1p]

Hi Everyone,

I have a question, what is the use or advantage of option "Fill un-used flash with 0xFF"? In my case I am using IAR IDE and ATMEGA1608. I can see it being used to make checksum but what if my flash is not filled with 0xFF, checksum should still be there!


Thank you.

[ataradov]

This option fills gaps between sections with a known value. 0xFF is selected because it minimizes the flash wear. If your program has multiple sections with gaps between them, then programmers are free to leave the old data when programming that image. If you then calculate CRC as one big chunk, you will include that random data into CRC calculation, making it incorrect.

[jzx]

Sometimes it is also to speed the burning. If after erasing all the bytes are FF, the programmer can skip these positions because burning a position is slow.
For one flash this time is not important, but for a factory making many it is.

[cv007]

This option fills gaps between sections with a known value. 0xFF is selected because it minimizes the flash wear.

Even though they would have to pick a value to use, and an erased value is a logical choice, I'm not sure flash wear would really enter the picture. The flash that gets erased/written every time at the very least would be the vector table, and it would not be a big win to have preserved some other flash locations while the vector table starts to fail. I would think it would be better to have every flash byte 'exercised' equally so they start to fail at the same time frame, giving you the max sample size of bytes as failure detectors. Probably makes little difference in most cases as one never approaches the flash writing limits by normal programming. If flash is used for runtime storage, then its on the app code to sort this out.

It seems to me this option would simply be for ranges of unused flash in pages otherwise left untouched by the programming process. In other words, if a flash page has code in it, it will be erased and any unused flash in that page will already be 0xFF.

For this avr, there is a choice the programming software can make- either program by pages or do a chip erase first then program the flash. It could simply be the ide has an option to do a chip erase disguised as 'fill unused flash with 0xFF', as a chip erase would be the easy way to do this.

One reason one may want to do this- you simply do not want remnants of previous code remaining in the mcu. If your currently loaded (flawed) code happens to get past the end of your app code for some reason, you end up in harmless instructions and will be able to detect the wrap-around (end up back at reset vector, startup code checks for any reset flag, if no flag you have a problem and are going to want to do a software reset). Also having a 'clean' mcu will mean anytime in the future you need/want to read the flash to see whats inside, you will not have to decipher pieces of code that are no longer part of the current app.

A reason to 'not' do a chip erase (fill with 0xFF), for this avr, would be if you have the avr setup to use the Application Data section. If you want to preserve that data between programming, you cannot do a chio erase as it would also erase that data. The programming software then most likely would do page programming, and the Application Data section would be untouched as its location will not have any code to program.

So, for this avr, I would do a chio erase (fill with 0xFF) unless I was making use of an Application Data section and I wanted that data preserved between programming. There could be other possible scenarios, but you will know when you are there.

[ataradov]

Even though they would have to pick a value to use, and an erased value is a logical choice, I'm not sure flash wear would really enter the picture.

It depends on the size of those gaps. Generally erase block is bigger than the program block and some blocks may not need to be programmed at all. Although it obviously does not matter in real life.

it would be better to have every flash byte 'exercised' equally so they start to fail at the same time frame

Flash performance varies from block to block way more than any damage you can do by differential programming.

It just had to be some value, and 0xff is a natural choice.

It could simply be the ide has an option to do a chip erase disguised as 'fill unused flash with 0xFF'

The option is for the binary file output. It will either output a HEX file with multiple sections, or a single section file with gaps filled. And for raw binary files, the gaps would be filled anyway.

My personal preference is to always fill and pad the file size to the erase block size. This way you get consistent behavior across all programmers. It may not matter in absolute majority of the cases, but it eliminates a few cases where it matters.

[cv007]

Generally erase block is bigger than the program block

Though we are talking about a specific mcu here- the mega1608, which is erased either in page sizes or via a chip erase. Flash writing in this mcu is then done via a page buffer (from a single byte up to a page).

I don't use IAR, but it looks like they have this option in the Checksum section, with the option to set the fill byte to the value of your choice (so is not really 'fill unused flash with 0xFF', its just that 0xFF is already filled in as the default value), along with the option to enable checksum (can do either, both, or neither).

Basically, it makes no difference what you do up until you want to use the checksum, or have some specific reason to fill unused flash. If you leave it unchecked, you can also do a chip erase (most likely an option in whatever software does the programming) and will get unused flash in its erased state.

[peter-h]

FWIW, the 32F4 can do circular buffers using DMA.

And IME the biggest speedup for FLASH programming is to do a pre-read and program only if different. Often the speedup is dramatic e.g. 100x.