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

[peter-h]

I have this in the production test and config.

Currently it is taking 120 seconds. There are 8192 blocks and each one takes 15ms (with pre-erase).

I am looking for a way to speed this up a lot because it is a bit of a bottleneck if you are processing say 100 boards.

There is a device erase command (45s typ.) but that sets it to 0xff. But then you can use the block write without pre-erase which is 3ms typ. That yields ~ 70s. Not much of a help really.

Other options are to not bother with this, but there are sound programming reasons for 0x00, similar to why BSS gets zeroed, setting any uninitialised variables to 0.

I just wonder if anyone knows of any tricks.

My SPI is running at 21MHz and I can't go any faster. But the data moving is worth only a few seconds (done with DMA so no gaps at all).

Currently my best idea is to perform some inspection and DVM tests on the next board while this one is zeroing itself.

[voltsandjolts]

Use 4MB MRAM?

[glenenglish]

change the memory bit charge threshold..

why do you want zeros anyway?.

[peter-h]

Check the pricing of 4MB 8-pin package alternatives

[Siwastaja]

1) Fix the underlying design expectation of all zeroes, and the problem just goes away;
2) If absolutely unable, parallelize the shit out of it. Have to test 1000 units? Build 10 test stations instead of one.

If you have to test just 100, then it's just easier to go with what you have, even if it takes 70 seconds, than to invest any time into making it faster - you can, at most, reduce total test time by 116 minutes.

For testing 500 units, process improvements start to sound appealing.

[peter-h]

The design does not rely on zeroed FLASH. It is just done (as I said before) for the same reason you zero BSS: to produce consistent results if something isn't right. I know your code has no bugs but I don't aspire to those heights myself, and C designers seem to agree

The other thing I thought about was to perform most of the zeroing as a background (one-off) RTOS task, when the other tests are being run. There is e.g. a factory test which takes a few mins, which is also an RTOS task, so that would work.

As an aside, I learnt a little lesson on this: It turns out that SPI1 can do 42MHz, whereas the other SPIs can do 21MHz max (168MHz CPU). But I made SPI1 inaccessible because the pin mapping forced that if I wanted four UARTs, and some other stuff. But as you rightly say that would not save any real time on this.

[Siwastaja]

But flash isn't random content after erase (like RAM is after powerup); 0xFF is as consistent as 0 is. For detecting accidental failure to clear, it's even better than 0, as it's a more rare default value, and thus will fail more visibly.

[peter-h]

Yes that's true. Well, apart from

- some of the device is storing floats of analog calibration values, and 0xffffffff is what float value? OTOH I could zero those areas very quickly...
- half the device is a FAT12 filesystem and 0x00.... is definitely not a directory entry, and probably offers better protection from corruption which is not avoidable with FAT especially as there is USB MSC (removable device) access also

I could achieve 45 secs (type data sheet figure) with the bulk chip erase. But no better, and the downside of that is that the background option mentioned above cannot be used because you cannot interrupt a bulk erase.

[WatchfulEye]

Yes that's true. Well, apart from
- some of the device is storing floats of analog calibration values, and 0xffffffff is what float value? OTOH I could zero those areas very quickly...

0xffffffff signals NaN in IEEE 754, which I would have thought would be ideal to represent an uninitialized value. 

[langwadt]

1) Fix the underlying design expectation of all zeroes, and the problem just goes away;
2) If absolutely unable, parallelize the shit out of it. Have to test 1000 units? Build 10 test stations instead of one.

If you have to test just 100, then it's just easier to go with what you have, even if it takes 70 seconds, than to invest any time into making it faster - you can, at most, reduce total test time by 116 minutes.

For testing 500 units, process improvements start to sound appealing.

https://xkcd.com/1205/

[voltsandjolts]

Yes that's true. Well, apart from

- some of the device is storing floats of analog calibration values, and 0xffffffff is what float value? OTOH I could zero those areas very quickly...
- half the device is a FAT12 filesystem and 0x00.... is definitely not a directory entry, and probably offers better protection from corruption which is not avoidable with FAT especially as there is USB MSC (removable device) access also

Erm, you are aware that the only way to go from 0 to 1 is by erasing a page/sector/chip, right? Clearing flash to zeroes prior to storing data in it makes no sense to me. I would say, erase the flash and write the data you need with block crc's as appropriate - that's the only way to be sure you have valid data, not whether it's all ff's or zeroes.

[Siwastaja]

Erm, you are aware that the only way to go from 0 to 1 is by erasing a page/sector/chip, right? Clearing flash to zeroes prior to storing data in it makes no sense to me. I would say, erase the flash and write the data you need with block crc's as appropriate - that's the only way to be sure you have valid data, not whether it's all ff's or zeroes.

Of course, but as always, this is again one of those trick question threads which lead to nowhere. I have nothing against this as it makes interesting discussions, but I want to point out the funny thing how some people here get banned for behaving like this, others do not.

[peter-h]

Of course, but as always, this is again one of those trick question threads which lead to nowhere. I have nothing against this as it makes interesting discussions, but I want to point out the funny thing how some people here get banned for behaving like this, others do not.

What complete BS.

Trick question?

It was a serious question. Somebody may have known a way.

[Siwastaja]

It was a serious question. Somebody may have known a way.

Oh, nearly everybody knows what you should do: abandon the idea of zeroing out the entire flash for reasons you mentioned, because those reasons are, as explained by others, made up and wrong (e.g. the float case, where NaN would be actually better than zero you suggest).

So as always, it's a classic X-Y problem where X is a weird and difficult problem to solve - and unnecessary, too. Just like treez topics.

[mikeselectricstuff]

Add an inverter to Dout?

[mikeselectricstuff]

If you are writing zeroes, you don't need to erase it first

[Siwastaja]

If you are writing zeroes, you don't need to erase it first

Possibly. As a generic advice however, always double-check from documentation and/or flash manufacturer: some flash memories have internal checksumming that limits writing cycles to one, and others, for some reasons I don't understand, specify that for longevity and reliability of data, only limited number of write cycles between erases is allowed, which could be as low as 1. For example, nRF52 microcontrollers specify max n_write between erases 2.

So it's always a good idea to check before assuming you can just arbitrarily zero out existing bytes without erase.

[langwadt]

If you are writing zeroes, you don't need to erase it first

and if you you write zeros you'll have to erase it before using it for anything else

*not all flash allows reprogramming a zero to zero

[Siwastaja]

and if you you write zeros you'll have to erase it before using it for anything else

Which is exactly why it's a bad idea to write some calibration table to zero on production, only to be erased and rewritten on the next (calibration) step. Just bulk erase the device once in production, leave calibration as all-ones, calibrate, and write calibration results (including CRC over the calibration block) to the already erased flash. Fast and simple.

[peter-h]

On this project every write is the whole 512 byte block and it is always in the pre-erase mode. That is guaranteed to work. It takes 15ms.

But if, on a particular block, you could be sure a pre-erase (a separate command) was done then you can do a "block write without pre-erase" which takes 3ms.

Hence the suggestion of a whole device erase (45s) and then 8192 x "block write without pre-erase 0x00" which is a bit faster overall.

The cal table is a very small part of the device and not relevant to the overall time. Half the device is a FAT12 logical drive and other parts are, ahem, other things...

One advantage of the initial zeroing is that it also tests the whole device which is a good idea in itself.

[DavidAlfa]

There's no way of making it faster, unless you're doing something wrong.
Are you waiting the time specified in the datasheet or polling the busy bit?
The latter will be way faster.

Why do you need to do this manually?
Set a checksum somehere, so if wrong the device automatically makes all the erasing/writing/verifying and initializes the default values.

[peter-h]

Polling the BUSY state (actually over SPI).

[DavidAlfa]

I think you simply should allocate all those variables into some specific(s) sector(s), adding a checksum.
If the magic is wrong, erase and write defaults, simple as that, don't trust random flash contents without checksums.

[abyrvalg]

BTW, BSS zeroing is not some optional paranoidal “just in case” BS trick, but a part of C standard. GCC relies on it and places explicitly zero-initialized vars to BSS instead of DATA to reduce the executable image size by not including those zeroes.

[peter-h]

Indeed, and it is required for
int fred=0;
but not "actually" required for
int fred;
which also ends up in BSS.
But maybe C guarantees that the latter fred will also be zeroed?