Fastest way to set Adesto AT45DB321E 4MB SPI FLASH to zeroes

[glenenglish]

If is is cal values, I generally use two copies.

If it is user settings, I put those in a single region of flash and divide up contiguous space into perhaps 32 sequential areas (or "records")   to contain the settings

To write/ update settings  the program walks through the 32 records and finds an erased 'copy' (all ff) with good CRC for that record
now it knows its up to a clean/erased  record, and writes the settings there.
. the next time it writes, it just finds the next record.

On load settings, the program walks through until it finds an erased record (ff) and backs up one step and loads those the RAM.

Eventually, the user writes the entire region and an erase is required . This can occur a page at a time , or if the user maintains TWO regions, say 64 records , then the whole region/ page/sector erase can be done independently in the 1st  region  from the data in the 2nd region.

CRCs are used for each set of setting records .

If the init program cannot find a good CRC, it  loads defaults into the region/record  and continues.

[bson]

Invert the SPI MOSI/MISO lines so 0xff reads like 0x00?

2x 74LVC1G04 FTW?

[bson]

By the way, doesn't that flash (sorry, too lazy to look it up) have sector/block erase?  If so you could check to see what actually needs to be erased and leave any sector or block that's already zeroed alone...  If you only use a part of it it might save time.

[peter-h]

Invert the SPI MOSI/MISO lines so 0xff reads like 0x00?

Yes, though I would need to also invert all the commands and status. One could do it.

By the way, doesn't that flash (sorry, too lazy to look it up) have sector/block erase?  If so you could check to see what actually needs to be erased and leave any sector or block that's already zeroed alone...  If you only use a part of it it might save time.

Yes there is the 45 sec device erase mentioned earlier. That, together with inverting the data (always 512 byte blocks in my case) would bring the 120s down to 45s.

One assumes that block erase actually tests the device to the extent of checking for all FFs. If it doesn't then there is another dimension: my zeroing the device (which arrives erased, AFAICS) tests the whole chip, at the cost of taking 120s.

But the block erase may not test the device at all, if it starts all-FFs. Then of course the "typical" time should be way less than 45s.

[Siwastaja]

I don't think there is any self-testing involved in erase operation. If there was, it would be a big red marketing point on the data sheet front page.

[peter-h]

Right, but how is the device erase performed?

You must not over-erase these devices, which to me sounds like they write zeroes and then perform the erase algorithm which ensures the right erase margin has been performed.

I don't see how they could verify an adequate erase margin without writing zeroes first. Same with UV EPROMs: you stick them under the UV lamp for half an hour and then write in the zeroes in the data until they read back correctly, and then four more times (or whatever - there were all kinds of adaptive schemes which were fast).

[Pseudobyte]

Ditch FAT12.
Implement littlefs on the whole device.
Emulate FAT12 from littlefs if you need external access like USB.

Built in wear leveling.
Power loss tolerant.
Checksum handled for you.
No need to erase the device at all.

I have even used littlefs for eeprom.

[peter-h]

Thank you. I had a look at Littlefs but it is rather tangential to all this. FAT12 also doesn't need zeroing, and runs directly over USB MSC to create a windows compatible USB drive. I am using FatFS for the FAT12 which has a vast user base and is rock solid. The API is widely used too and I could not re-hash what I have.

The flash wear issue is not an issue in my project because the usage is for config files, firmware files, etc, not for data logging. I have a separate feature for data logging, with wear levelling and its own API. But I have also put in an 8MB PSRAM which will never wear out... actually one could use FatFS to create another logical drive, FAT16, within that too.

[Pseudobyte]

Gotcha, yeah I guess my point was who cares what state the flash is in when you are using a filesystem. Why not expand the FAT filesystem to the entirety of the flash space?

[peter-h]

It already is 50% of it (2MB).