Question about flash memory as used in an SSD or MCU

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

I hope this is in the correct forum. If not, mods please move it and my apologies.

OK... we know that EEPROM and FLASH memory must be erased prior to writing (that is, bytes or blocks need to first be erased so that all bits are 1, resulting in lots of 0xFF data).

But, a new SSD if not formatted is filled with 0x00 data (i.e. reading it returns all zeroes).

So, my question(s) are:

* Is the data which is read or written INVERTED (that is, would a byte of data 0x55 be stored in flash as 0xAA)?

* If NO, then shouldn't an "erased" drive be filled with 0xFF instead of 0x00?

* Since an erased MCU such as an AVR reads back as all 0xFF, can I assume that data inversion is NOT used here?

(by the way, my "goal" with this is to write a "program more zeroes" algorithm to make flash and/or eeprom cells last a bit longer). It's nothing "important", just a learning experiment.

Any info about this will be appreciated.

Gentlemen may prefer Blondes, but Real Men prefer Redheads!

Last Edited: Fri. Dec 13, 2019 - 07:32 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

With a ssd, formatted does not mean erased. I have not actually tried reading a raw sector from a ssd, so i have no idea what the initial state is, however, something must be written to initialise the ECC for each sector.

Last Edited: Fri. Dec 13, 2019 - 07:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Also note that ssd uses NAND flash whereas the AVR uses NOR flash. These are very different.

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

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

Kartman wrote:
With a ssd, formatted does not mean erased. I have not actually tried reading a raw sector from a ssd, so i have no idea what the initial state is, however, something must be written to initialise the ECC for each sector.

I know that of course. What I was saying was that if I buy a new SSD (msata, sata, whatever) it usually comes as blank and unformatted requiring me to first run parted to create the "partition" (the 512 byte thing in sector 0 that has the pre-boot code, the drive geometry, etc... and ending in 0x55, 0xAA). Then I run mkfs.ext4/.ntfs/.exfat/.whatever to format the drive. But BEFORE any of this is done, the drive is blank, unpartitioned and unformatted and every byte is 0x00. This is determined by running hexedit /dev/sdx and looking at the raw data. Any ECC data the drive has is between the storage media itself and the drive controller silicon. That data is not normally exposed to the user and special ATA "read sector raw" commands are required to see that data at all. The error correction codes are not what I was talking about anyway.

Gentlemen may prefer Blondes, but Real Men prefer Redheads!

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

Kartman wrote:
Also note that ssd uses NAND flash whereas the AVR uses NOR flash. These are very different.

I know that. What I was wondering was if certain controllers in devices like SSDs invert the data so that "1" bits on the data bus are actually stored as programmed "0" bits. I ask because an ERASED flash byte is all 1s (resulting in 0xFF in flash which appears to the outside world as 0x00, leading me to assume that data on the bus is inverted before writing it to flash and inverted back to normal when reading from flash to send to the data bus. You see what I'm asking?

Gentlemen may prefer Blondes, but Real Men prefer Redheads!

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

Kartman wrote:
...however, something must be written to initialise the ECC for each sector.

An SSD is initialized at the "factory". This includes calculating then writing the initial error correction code data as well as mapping out defective pages of flash (wafer level defects on the chip) and setting up the pool of spare pages of flash (provisioning). During the life of the SSD, ECC data is calculated on the fly and written to flash along with the data itself as well as using the ECC to verify and, if necessary (and possible) correct bit errors in the data read from flash. Also, data is moved around to different flash pages (wear levelling) and pages that die of old age (wear out or have ECC uncorrectable data errors) are mapped out and replaced with pages from the pool of spares. Of course, all of this has nothing to do with what I originally asked in post #1.

Gentlemen may prefer Blondes, but Real Men prefer Redheads!

Last Edited: Fri. Dec 13, 2019 - 11:22 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So maybe the process of "initialising" at the "factory" leaves the data at all zeros .. ?

 

Krupski wrote:
BEFORE any of this is done, the drive is blank, unpartitioned and unformatted and every byte is 0x00. 

On what do you base this?

 

Is this guaranteed, or is it just what you happen to have noticed?

 

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

awneil wrote:

On what do you base this?

 

Is this guaranteed, or is it just what you happen to have noticed?

It's my experience too. As far as I know all of CF Cards, USB memory sticks and SSDs all come with all sectors written to 0x00. As Krupski says this is counter-intuitive as the electrons on the gates of NAND default to '1' in the erased state (so 0xFFs). It does make you wonder if they are doing something "clever" inside to invert the data or something (so that when we read 0x00 the array is really holding 0xFF) but I think only an engineer involved in the design of SSD/CF/MSD would really know what they are doing "inside" the controller software of the memory device.

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

awneil wrote:

So maybe the process of "initialising" at the "factory" leaves the data at all zeros .. ?

 

Krupski wrote:
BEFORE any of this is done, the drive is blank, unpartitioned and unformatted and every byte is 0x00. 

On what do you base this?

 

Is this guaranteed, or is it just what you happen to have noticed?

 

I'll amend the statement: All the bytes I can see (i.e. user data, not specialty data such as ECC and defect management) are 0x00.

Gentlemen may prefer Blondes, but Real Men prefer Redheads!

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

clawson wrote:
 It does make you wonder if they are doing something "clever" inside to invert the data or something

Or it it's just part of the "initialisation" process which leaves everything at zero - whether by design or "coincidence".

 

 I think only an engineer involved in the design of SSD/CF/MSD would really know what they are doing "inside" the controller software of the memory device.

Indeed. And whether it is something you can rely upon or not ...

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...
Last Edited: Fri. Dec 13, 2019 - 12:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

clawson wrote:

It does make you wonder if they are doing something "clever" inside to invert the data or something

Or something.

 

All modern SSD use MLC.  Notions of 0 and 1 per cell are no longer accurate.

 

Krupski wrote:

I'll amend the statement: All the bytes I can see (i.e. user data, not specialty data such as ECC and defect management) are 0x00.

You're seeing what the SSD controller is showing you.  You do not have access to the flash cells themselves.  For all you or I know, an all-zero 'device' sector is handled specially.  Maybe it's just a flag that says to the controller "ignore the contents of this sector and just report all zeros".  This would make sense to me since an all-zero sector is common with typical filesystem usage.  Special handling would reduce wear in these cases.

 

You can't draw much of a meaningful comparison between and SSD with GB of high-speed storage, and a microcontroller with a few kB of single-port flash.

"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]