[thebruce87m]

> The degradation increases the amount of negative charge in the cell over time due to trapped electrons in the oxide and negates some of the control gate voltage, this over time also makes erasing the cell slower, so to maintain the performance and reliability of the NAND chip, the cell must be retired from use.

https://en.m.wikipedia.org/wiki/Flash_memory

IIRC from when I worked making microcontrollers, there is a feedback loop on the erase that makes sure the bits all read 1 as they should. This takes longer based on how many write/erase cycles have occurred.

I’d have loved to find an actual data sheet to show you as an example, but here is something I found:

https://e2e.ti.com/support/microcontrollers/arm-based-microc...

> The erase time is worst case for a single sector when doing sector erase, or the whole bank if doing bank erase. In bank erase all the sectors are being erased at the same time so the time of the bank erase is equal to the time to erase the slowest sector.

> Erase time degrades with the number of write erase cycles. Sometimes during erase traps (an extra electron or hole stuck in the oxide lattice) are formed in the erase oxide. These traps make the next erase harder. Some of the traps will anneal with time and high temperature.

[malfist]

Flash memory does not erase during user actions. TRIM is done async

[ssl-3]

Flash memory is always erased during user-initiated writes in instances where trim is not used, or when there are not enough known-erased blocks to hold the write -- for whatever reasons these conditions may exist.

At a low level, a block of flash can't be written without being first erased. It might have been erased previously (which is ideal), but it might also might need to be erased immediately (which is much slower) in order for to perform a write operation.

And a trim command doesn't guarantee erasure of a low-level flash block -- it's up to the controller to sort out that out on its own.

[thebruce87m]

> Flash memory is always erased during user-initiated writes in instances where trim is not used

Great answer but slight nit pick: In my world (embedded) the flash on (some? dare I say most?) microcontrollers is only erased when you specifically tell it to erase. You can write to sectors multiple times without erasing. You can even write to the same word multiple times, as long as you only want to turn 1’s to 0’s. If you want to turn any 0 to a 1 in the whole sector then that’s when the erase comes in.

This gives interesting use-cases where you can count up using individual bits without a time-consuming/power-using/cycle-consuming erase.

[ssl-3]

Solid nit pick. I appreciate it.

(And somewhere in the back of my head I knew of this method of writing useful things to flash. It certainly has at least a couple of efficiency advantages that can be important in some cases, even if they're not the kinds of things that would be important or even usable with a consumer-oriented flash device that is operated from a high level.)

[thebruce87m]

It’s a good point, but the blanket statement isn’t true. Not all flash memory devices support TRIM.