Default Flash Memory state

[janpieterderuit]

Hi,

from some posts I get that the default state of Flash Memory (after erase) is "0", instead of "1", which is normal for Flash memory:

Flash programming granularity LPC55 

LPC55S69 : erased flash state 

And I also see this myself when trying.

To verify this:

• Erase a page
• Program all 1's to a page
• Read the page (all bits are "1")
• Program all 0's to a page
• Read the page (all bits are still "1")
• Erase the page again
• Program all 0's to a page, except the first word (so you won't get a hardFault ECC error when reading)
• Read the page (all bits are "0", except the first word)
• Program all 1's to a page
• Read the page (all bits are "1")

But this is not documented anywhere, and also not confirmed in the above mentioned forum post.

Can someone please confirm this default Flash memory state?

[ZhangJennie]

Jan,

For most of LPC parts, Flash memory after erase is 1. write action is to change 1->0.

BUT, 

for LPC55S69, it's different. Flash memory after erase is 0, write action is to change 0->1.

In addition, please pay attention to AHB read Hardfault error as I documented below

[LPC55xx] How to fix AHB Read HardFault Error 

Have a great day,
Jun Zhang

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[janpieterderuit]

Hi Jun,

thanks for the quick response.

Sorry, I wasn't fully clear with my question, so just to be sure:

This counts for the whole LPC55xx series, right?

Currently we are working with the Secure LPC55S28 (on the development board), and I tested the Flash memory default state on that.

But out final product will have a (non-secure) LPC5526.

The Flash memory default state is also "0" on this processor?

And just out of curiosity: is there any particular reason to invert the default state compared to normal Flash memory?

Thanks,

Jan Pieter de Ruiter

[ZhangJennie]

Hi Jan

Please hold on.

My first reply is based on my working experience with MCUXpresso IDE.

By further investigation, I find something conflict. I am checking with IDE team if memory show has issue. 

I will keep you informed.

Best Regards

Jun Zhang

[janpieterderuit]

Well, I don't use MCUXpresso IDE (I use Eclipse), and I didn't check by looking into the registers with a view, just purely by using the FLASH_Read command.

[ZhangJennie · Accepted solution]

Jan,

By internal checking, I can confirm my initial reply is correct. LPC55xx parts uses 0 as erased value (as opposed to most of the other flash devices which use 1 as erased value)

Have a great day,
Jun Zhang

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[bernhardfink]

We did not re-invent flash technology for the LPC55XX MCU family, but we enhanced the features: we added ECC.

This means that there is now a functional block in between the read entity (for example the CPU) and the flash itself. The User's Manual mentions this shortly in chapter 5.7.13:

When writing, parity is automatically computed and stored alongside user data. When reading, data and parity are used to reconstruct correct data, even in the case of a 1-bit error.

When reading an erased location, an uncorrectable error is flagged. Use the “blank check” command to test for successful erase.

Read access to an erased flash location is a non-defined state for the ECC controller, so we cover this with a pre-defined output. I assume that without the ECC controller the feedback from an erased location would be 0xFF as from all other standard flash parts I know.

So for the LPC55XX parts the "erased value" is an artificially generated value, just because of the ECC feature.

Regards,

Bernhard.

[janpieterderuit]

Hi Bernhard,

thanks for your feedback.

The flash bit state is always inverted by the in-between block, not only for erased flash, right?

Because I can program a 0 to 1, not 1 to 0.

I don't see what the inversion would be needed for (0xFF could also just have been the pre-defined output for an erased word), but at least we now know, and we can work with it.

Jan Pieter de Ruiter

[bernhardfink]

Hi Jan,

you can't see it this way. The ECC value is an add-on value which is taken into account when the flash value is read/written. In case of an erased flash location there is no ECC value and this is taken into account when you read from this location. If you now write to the flash location, let it be 0xFFFF FFFF, then there will be an ECC generated and if you now read from this location you will see it as 0xFFFF FFFF. Same rule for any other other value, what you write can be read.

Now to the question what happens when you program 0xFFFF FFFF in a first step and 0xF0F0 F0F0 in a second step into the same location:

Due to the presence of ECC, over-programming an already programmed word will likely result in inconsistent parity bits; for this reason, it is not allowed to program a memory word without erasing it first.

"... will likely result ..." means that we did not investigate all possible problems when it's written more than once, per spec it's simply not allowed. But you can of course easily do tests.

I expect that the initial content is (virtually) 0xFFFF FFFF, you write 0xFFFF FFFF, nothing changes, you write 0xF0F0 F0F0, content changes at the respective bits from '1' to '0', but now with errors on the ECC value.

Regards,

Bernhard.

[janpieterderuit]

Hi Bernhard,

thanks again for you reply.

It really helps me to understand the matter.

But I'm a bit confused now.

Here's what I understand about reading/writing the flash in an LPC55xx:

• You can only erase a whole page (512 bytes aligned address and size)
• You can only write data to a whole page (512 bytes aligned address and size)
• You should only program a word once, unless you erase the page
• You can read on bytes
• You should not read from an erased page (due to ECC), unless some data has been programmed in the page
• Erased flash will return 0x00
• Programming means switching zero's to one's (at API level, FLASH_Read/FLASH_Write commands)

So writing '0xFFFF FFFF', as you suggested, will program all bits in the word, and you can't set it to zero's anymore.

Writing '0xF0F0 F0F0' afterwards will not change anything, I suppose.

But I think you suggest the other way around:

After an erase (flash is 0x0000 0000), you write 0x0000 0000 (nothing changes) and then write '0xF0F0 F0F0'.

And if I understand you correctly, this is not recommended, because you can only program it once?

But I would say that the first write ('0x0000 0000') does not program the word, and thus the word can be programmed with 0xF0F0 F0F0 without problem.

Else it wouldn't make sense to state that a word can only be programmed once, because then you have to write a whole page.

To clarify a bit, we have a usecase where we append data to the flash over time.

So we start with an erased flash page.

Then we want to append 0x0101 0101, so we write (512 bytes total) 0x0101 0101 0000 0000 0000 0000 0000 0000 etc.

Expected Flash content: 0x0101 0101 0000 0000 0000 0000 0000 0000 ...

Then we want to append 0x0110 1001, so we write (512 bytes total) 0x0000 0000 0110 1001 0000 0000 0000 0000 etc.

Expected Flash content: 0x0101 0101 0110 1001 0000 0000 0000 0000 ...

Then we want to append 0x0111 1000, so we write (512 bytes total) 0x0000 0000 0000 0000 0111 1000 0000 0000 etc.

Expected Flash content: 0x0101 0101 0110 1001 0111 1000 0000 0000 ...

(Note: I'm talking about the bitstate at API level here, not the actual state of the flash bits).

So each time the words that have been programmed before will be written again, but since we do it with all zero's I would say they are not programmed, and thus there is no problem.

Is that assumption correct?

If not, the internal flash is not useful for us, as you can only really write a page at a time.

Thanks, Jan Pieter