Fastest way to set Adesto AT45DB321E 4MB SPI FLASH to zeroes - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: August 05, 2024, 08:01:35 pm
content: 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.

author: voltsandjolts
author_rank: Unknown
timestamp: August 06, 2024, 07:20:01 am
content: Use 4MB MRAM?

author: glenenglish
author_rank: Frequent Contributor
timestamp: August 06, 2024, 07:26:25 am
content: change the memory bit charge threshold..why do you want zeros anyway?.

author: peter-h
author_rank: Super Contributor
timestamp: August 06, 2024, 02:46:11 pm
content: Check the pricing of 4MB 8-pin package alternatives

author: Siwastaja
author_rank: Super Contributor
timestamp: August 06, 2024, 02:51:52 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 06, 2024, 03:07:32 pm
content: 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 agreeThe 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 06, 2024, 04:09:14 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 06, 2024, 04:56:18 pm
content: 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 alsoI 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.

author: WatchfulEye
author_rank: Regular Contributor
timestamp: August 06, 2024, 09:12:51 pm
content: Quote from: peter-h on August 06, 2024, 04:56:18 pm0xffffffff signals NaN in IEEE 754, which I would have thought would be ideal to represent an uninitialized value.

author: langwadt
author_rank: Super Contributor
timestamp: August 07, 2024, 12:19:04 am
content: Quote from: Siwastaja on August 06, 2024, 02:51:52 pmhttps://xkcd.com/1205/

author: voltsandjolts
author_rank: Unknown
timestamp: August 07, 2024, 08:35:52 am
content: Quote from: peter-h on August 06, 2024, 04:56:18 pmErm, 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 07, 2024, 09:09:27 am
content: Quote from: voltsandjolts on August 07, 2024, 08:35:52 amOf 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 07, 2024, 09:49:32 am
content: QuoteWhat complete BS.Trick question?It was a serious question. Somebody may have known a way.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 08, 2024, 10:35:39 am
content: Quote from: peter-h on August 07, 2024, 09:49:32 amOh, 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 actuallybetterthan 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 08, 2024, 10:39:10 am
content: Add an inverter to Dout?

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: August 08, 2024, 10:41:13 am
content: If you are writing zeroes, you don't need to erase it first

author: Siwastaja
author_rank: Super Contributor
timestamp: August 08, 2024, 11:04:31 am
content: Quote from: mikeselectricstuff on August 08, 2024, 10:41:13 amPossibly. 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.

author: langwadt
author_rank: Super Contributor
timestamp: August 08, 2024, 11:07:21 am
content: Quote from: mikeselectricstuff on August 08, 2024, 10:41:13 amand 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

author: Siwastaja
author_rank: Super Contributor
timestamp: August 08, 2024, 11:25:08 am
content: Quote from: langwadt on August 08, 2024, 11:07:21 amWhich 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 08, 2024, 11:41:03 am
content: 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 whichisa good idea in itself.

author: DavidAlfa
author_rank: Super Contributor
timestamp: August 08, 2024, 08:53:06 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 08, 2024, 09:01:28 pm
content: Polling the BUSY state (actually over SPI).

author: DavidAlfa
author_rank: Super Contributor
timestamp: August 08, 2024, 09:48:20 pm
content: 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.

author: abyrvalg
author_rank: Frequent Contributor
timestamp: August 09, 2024, 11:52:47 am
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 09, 2024, 01:01:48 pm
content: Indeed, and it is required forint fred=0;but not "actually" required forint fred;which also ends up in BSS.But maybe C guarantees that the latter fred will also be zeroed?

author: DavidAlfa
author_rank: Super Contributor
timestamp: August 09, 2024, 01:17:51 pm
content: Quote from: peter-h on August 09, 2024, 01:01:48 pmAFAIK by C spec, it inits allglobalvariables as zero unless specified otherwise.But this doesn't apply to local variables.Code:int var1; // var1 value will be 0void main(void) {int var2; // var2 value will be undefined. Normally you'll get a compiler warning about this.}

author: artag
author_rank: Super Contributor
timestamp: August 09, 2024, 07:53:09 pm
content: That's not a local, its an auto.A variable declared outside a procedure is global unless marked 'static', but both guarantee zero if not set otherwise.Static can also be declared inside a procedure in which case it's again in Bss or data (but has scope of the procedure rather than the module/source file).ONLY auto is not initialised if no value is given.These are all behaviours which can and should be relied on. The only advantage to explicitly setting something (other than an auto) to zero is to help the person reading it (who should know better anyway).Getting back to the original subject, is there a driver that transfers the eeprom into addressible memory and performs a save when scheduled ? If so, it could invert all the bits during the transfer, then the erased state of FF would appear to the code to be 00.

author: peter-h
author_rank: Super Contributor
timestamp: August 09, 2024, 08:55:35 pm
content: There isn't a driver as such but since a function gets called to read or write the device (via the 21MHz SPI) this function could trivially invert the data, so 0x00 is actually stored as 0xff. That's really cunning!I bet you lots of people have done that beforeEPROMs also come up as 0xff.

author: glenenglish
author_rank: Frequent Contributor
timestamp: August 11, 2024, 01:55:41 am
content: Quote from: Siwastaja on August 08, 2024, 10:35:39 amYep that is the best answer. I have come back to this thread after a few days away, and Is this guy still wanting to have all zeros for all the wrong reasons, ignoring decades of informed and experienced advice provided ?You know Peter, you can accept you've got it crazy wrong .... It's OK.

author: peter-h
author_rank: Super Contributor
timestamp: August 11, 2024, 05:33:00 pm
content: I think one or two of you guys really enjoyed being at (what in England is called) a boys' public school.The best suggestion is to invert the data which comes back, in software. It is all whole 512 byte blocks in my case, 21MHz SPI, DMA, so an overhead of about 2us to invert it in software, using 128 32 bit operations, preferably with a 4-aligned buffer. Astonishing. And of course invert write data too.Then all the built-in block / whole device erase commands produce zeroes.

author: wek
author_rank: Frequent Contributor
timestamp: August 11, 2024, 07:16:51 pm
content: QuoteYou know you are now shooting dangerously close to your foot, don't you?JW

author: peter-h
author_rank: Super Contributor
timestamp: August 11, 2024, 07:51:58 pm
content: Well you must not invert the commands, addresses, etcWhat else is wrong?

author: DavidAlfa
author_rank: Super Contributor
timestamp: August 11, 2024, 08:58:41 pm
content: He probably has some function like Read/WriteData(adr, *buf, size) so inverting the data should be fine!

author: wek
author_rank: Frequent Contributor
timestamp: August 12, 2024, 11:05:10 am
content: He probably has sights on the gun, maybe even ared dot... what could possibly go wrong?;-)My painful experience is, that problems creep in later, much later, years later, when the "nonstandard details" one has in mind while working on the thing continuously, have already vanished...Yes, I do things in unorthodox ways, when justified. And I comment them maniacally. And have been bitten nonetheless.Just sayin'...Meantime,some funwith sFLASH.JW

author: abyrvalg
author_rank: Frequent Contributor
timestamp: August 12, 2024, 11:42:55 am
content: Go further! Add a BusFault handler returning 0 to all stray mem accesses. If you mask all problems there will be no problems

author: artag
author_rank: Super Contributor
timestamp: August 12, 2024, 12:12:53 pm
content: Using something that has no valid meaning - like NaN - is undoubtedly a better solution. As wek indicates, it's best to deal with problems rather than cover them up.However, iiuc, you have a body of existing code that assumes zero to mean 'uninitialised'. It wasn't the best choice but if we assume it's been in use a while and perhaps is a convention used on other products too, you have quite a lot of work in changing it, and changing unaffected but si,milar code to match the convention.If you don't correct that thoroughly you might start getting bad behaviour from code that previously failed silently. This is good in the long run but not in the short run.You can also argue that, in an embedded application. you don't want exceptions. Certainly not uncaught exceptions. In a non-critical desktop application it might be better to report a problem and halt. That's almost never an option in embedded - ideally you want to deal with everything fully but at worst a strategy of being wrong but consistent and still running the rest of the application is better. Sometimes, but not always, a restart is acceptable.It's up to you / your employer to decide whether it's working. Your managers are likely to think 'if it's not broke, don't fix it' and than can be a valid business decision. Only someone with the whole picture can make that choice.Personally, and knowing only what I can guess about your application, I would probably use the inversion system. It solves your immediate problem and doesn't make anything else worse. But I would also instigate a review of whether the zero default is a good choice and perhaps consider changing it globally.

author: DavidAlfa
author_rank: Super Contributor
timestamp: August 12, 2024, 05:02:10 pm
content: It's NaN for floats, but not for integers...

author: peter-h
author_rank: Super Contributor
timestamp: August 12, 2024, 06:25:08 pm
content: QuoteInteresting bit of funThe chip I am using has 512 byte sectors and it is always accessed that way, only. That device was chosen because it is ideal for a FAT12 filesystem via USB MSC. A larger block size, or a larger erase unit, etc (a lot of bigger flash chips use a 4k erase unit) would need what under CP/M used to be called blocking and deblocking and is a PITA because you also need a timer based flush process. With USB MSC (removable storage device) you must provide a 512 byte blocksize to the USB Host (Windows etc).QuoteI do that too. It's not perfect but it is all one can do.QuoteSure. As I wrote earlier I don't actuallyneeda zero default anywhere, other than for the same CYA reason that "int fred;" goes into zeroed BSS. Yes I now know that a C coder is entitled to assume it yields "int fred=0;" but I didn't know that, and doubt it was always true in C, not to mention other languages like Fortran or Pascal. I cut my teeth in asm, many years of it, where you assume nothing of the sort, and I am damn sure 1980s C compilers did not guarantee that.As regards NaN, it doesn't help in an embedded system which cannot report errors. How do you test a float for being == NaN?Actually you cannot test a float for zero either, can you, with the == equality?So I don't think NaN is useful at all. Whereas a zero might be because a zero zero error is, ahem, a zero zero error, and a zero scale value will yield a zero output, which is kind of obvious...But anyway NaN floats are not the main reason for zeroing the flash. Most cal values I am storing are actually around 1.The system has a negligible zero error by design - another story - check out e.g. TLV2333 zero specs and you get the idea. The main reason is mainly the FAT12 partition. Even that doesn't need it if there is no corruption.

author: langwadt
author_rank: Super Contributor
timestamp: August 12, 2024, 07:41:50 pm
content: Quote from: peter-h on August 12, 2024, 06:25:08 pmif the guy writing the init code screws up there's not much the compiler can do, but K&Rs first draft of "The C Programming Language" from 1977 said: "Static and external variables which are not initialized are guaranteed to start off as 0;" and it is still there

author: glenenglish
author_rank: Frequent Contributor
timestamp: August 12, 2024, 08:18:28 pm
content: Any critical calibration variables you store should at least be protected by error detection like CRC...IE hold your cal data (or whatever it is ) in a structure with its own CRC, and make dirty when something is changed etc, and have two copies.*** flash errors do happen - so I would expect you must wrap the entire thing in ECC .I think your choice of zeros to make non initialized values safe is flawedyou said : "So I don't think NaN is useful at all. Whereas a zero might be because a zero zero error is, ahem, a zero zero error, and a zero scale value will yield a zero output, which is kind of obvious..."again, you need explicit initialization, and data protection of your cal data.Consider that when it starts up, it needs to examine all the cal data to assess usability and integrity, and load defaults or load from an 2nd copy as required. You can never assume anything with initialization if its critical data that may upset the product.

author: peter-h
author_rank: Super Contributor
timestamp: August 12, 2024, 09:18:22 pm
content: QuoteThis is getting off topic a bit but I wonder how many people really do that, in products like data loggers. I am not actually making a data logger here but for the purposes of this debate it is a similar thing. It's a product with a 16 bit ADC subsystem but only 0.1% resistors, so factory cal is needed, even for mundane things like PT100 reading to Class B level.I've been using EEPROMs and FLASH chips since the 1980s and never stored anything twice. Also never used CRCs across data (which introduces the problem that the CRC gets concentrated wear, unless you use more esoteric schemes to spread that out). Sold tens of thousands of products and never had problems.If FLASH in general lost data then the whole microcontroller business would be dead because code would never run

author: Siwastaja
author_rank: Super Contributor
timestamp: August 13, 2024, 08:36:30 am
content: Quote from: peter-h on August 12, 2024, 06:25:08 pmYour life would be easier if you did simple Google search each time, instead of assuming things must be difficult and problematic.You use isnan() from math.h. And yes, you can test floating point number equality with zero ( == 0), and also any other integer (excluding massively huge numbers).If you don't find the NaN feature useful, then fine. It was you who suggested that zero is a good indication of some kind of accidentally uninitialized value, which it is not. NaN is better. Best is to just use checksums over important areas and check the checksum as the first thing, after which you can assume all variables are valid.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 13, 2024, 08:49:43 am
content: Quote from: peter-h on August 12, 2024, 09:18:22 pmThe choice is quite easy to make (and the same logic applies to stuff like firmware itself, calibration values or user settings):1) If you are certain things are only written during manufacturing, you don't store twice.2) If you want on-the-field / end user update, you do store things twice (or use some of more complicated schemes, but double storage is the simplest to understand). This is because, as you know, flash memory requires non-atomic erase-write cycle, where erase cycle is painfully slow. Simple power outage during update loses the data forever, and it will inevitably happen.Exception to 2 would be, if you have a recovery mechanism so that data upload can be simply retried. For example, PC software which sends calibration values into the device can just read them out to see if the CRC is correct and re-try until success, as long as the firmware is capable of updating the values even when they are incorrect. No need to double store.But, for example, if we are talking about firmware update, and you need working firmware to update the firmware, two copies of the firmware is pretty mandatory, and yes, everybody does it. Otherwise Murphy's law dictates that the power loss happens exactly during flash erase.

author: peter-h
author_rank: Super Contributor
timestamp: August 13, 2024, 09:08:20 am
content: QuoteNot if the new firmware is stored somewhere temporarily, CRC checked etc, and you have a "boot block" which can re-flash from that temporary store if the CPU flashing failed.But yes I get your drift. What is needed is a recovery mechanism. It is however not the same as the previous guy who said everything must be stored twice.The Adesto flash does actually have a funny problem (described in some appnote) that if you do a block erase (which could be the whole 45 second device erase) and lose power, the device can end up in an undefined state in some part(s) of it, because of an algorithm they use for erasing which repeatedly performs an erase cycle until all the bits (I assume they mean all the bits in a 512 byte block; it would be silly to be doing this across 4MB) have a good "erased bit" margin. Not dissimilar to the old UV EPROM programming algorithm where you pulsed it until the byte read back right and then you gave it four more pulses (I designed a number of those in the 1980s).

author: Siwastaja
author_rank: Super Contributor
timestamp: August 13, 2024, 09:12:09 am
content: Quote from: peter-h on August 13, 2024, 09:08:20 amYeah but that "somewhere temporarily" is same amount of space needed - itisdouble storage by definition. Of course you could then erase it after the fact, andmaybeuse the same space for some other purpose, but rarely embedded applications are so dynamic in nature to enjoy this kind of "sometimes available" temporary storage space.In embedded project where stuff is statically allocated anyway I just prefer the simplicity of two firmware copies where bootloader chooses which one to run. You can achieve the same by making the bootloader take a copy of the "temporary buffer" and then run always from the same init address, but both approaches require the same amount of flash. The latter (bootloader takes copy) is obvious when the MCU flash is too small and you add external flash chip for the second copy, since it would be slow (or impossible) to run code off that chip directly.

author: Jon_S
author_rank: Contributor
timestamp: August 13, 2024, 01:41:23 pm
content: Quote from: peter-h on August 12, 2024, 09:18:22 pmJust as a piece of annecdata for you, I do this on products of all volume/cost where possible. Settings and the like are stored as ping-pong A/B blocks with a sequence number and a CRC in each block. Earlier on in my career I was involved with a product that had a small, but not zero, number of returns where mysterious corruption had occurred in the naïvely-stored settings area. I count it as as worthwhile development time to include this on everything, and consequently reduce returns and unhappy (or at least less-happy, as it wasn't very frequent) customers.I also use CRCs generally for blocks of data, it just seems like cheap and simple insurance against misbehaviour. I don't generally have the sheer volume of writes to the same element to need wear-levelling though.

author: peter-h
author_rank: Super Contributor
timestamp: August 13, 2024, 02:59:38 pm
content: What device did you use?Upon bad CRC detection, one should copy the good "sector" to the bad one.I went through this when doing the 32F417 boot loader. I program each block (typically 16k or 32k) up to 5x if it fails, but have never seen any failures. That's the CPU FLASH, not the Adesto FLASH, however.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 13, 2024, 04:00:57 pm
content: Quote from: peter-h on August 13, 2024, 02:59:38 pmPossibly, or just leave it there - whatever was the reason for corruption is very unlikely to repeat on the other half. Most likely the flash itself is OK, and the "bad" half recovers by the next erase-write cycle.I do the exact same A/B + CRC + sequence number thing, which I kind of invented on my own, just like thousands of others probably did, because it's simple and quite self-evident.For example, current project has two main sections for firmware, each of which further carry two copies of configuration (so 4 configuration copies total). Yes, it wastes space, but is both simple and robust, which I like. There is very little management, and not much copying of anything. Just pick A or B based on (crc_ok && count_mine > count_other), and when writing, write count_mine = count_other+1.

author: Jon_S
author_rank: Contributor
timestamp: August 13, 2024, 05:14:44 pm
content: Quote from: peter-h on August 13, 2024, 02:59:38 pmGenerally its the AT45DB641E, many flavours of EEPROM, and table writes for dsPICs and the like. I do copy on detection of a problem, because I don't like the idea of lost redundancy for longer than it can be helped. And the CRC bytes are the last thing written to the blocks, so a partial/failed copy has no downside in terms of making the situation worse.On things that are only protected with a CRC they typically just get left alone (and eventually overwritten), the user generally gets a message of some kind that the offending block of data is unavailable when the logs are downloaded etc...

author: peter-h
author_rank: Super Contributor
timestamp: August 13, 2024, 06:29:36 pm
content: Have you seen data loss on the AT45DB641E?

author: glenenglish
author_rank: Frequent Contributor
timestamp: August 13, 2024, 09:15:31 pm
content: 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 settingsTo write/ update settings the program walks through the 32 records and finds an erased 'copy' (all ff) with good CRC for that recordnow 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.

author: bson
author_rank: Unknown
timestamp: August 13, 2024, 10:13:48 pm
content: Invert the SPI MOSI/MISO lines so 0xff reads like 0x00?2x 74LVC1G04 FTW?

author: bson
author_rank: Unknown
timestamp: August 13, 2024, 10:17:15 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 14, 2024, 06:37:38 am
content: QuoteYes, though I would need to also invert all the commands and status. One could do it.QuoteYes 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.

author: Siwastaja
author_rank: Super Contributor
timestamp: August 14, 2024, 08:23:00 am
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 14, 2024, 08:48:27 am
content: Right, but how is the device erase performed?You must not over-erase these devices, which to me sounds like they writezeroesand 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 hourand 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).

author: Pseudobyte
author_rank: Frequent Contributor
timestamp: August 14, 2024, 01:43:34 pm
content: 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.

author: peter-h
author_rank: Super Contributor
timestamp: August 14, 2024, 02:21:26 pm
content: 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.

author: Pseudobyte
author_rank: Frequent Contributor
timestamp: August 14, 2024, 06:41:23 pm
content: 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?

author: peter-h
author_rank: Super Contributor
timestamp: August 14, 2024, 06:54:35 pm
content: It already is 50% of it (2MB).