Programming a self test for a SPI FLASH memory?

What is it you are trying to achieve? For example...

• Prove the flash is usable.
• Prove the data it contains is valid.
• Detect and correct invalid data.

How often is the test to be performed?

• Continuously.
• Periodically.
• On start up?

etc.

This test is going to be run after pcb assembly to confirm that the spi flash is usable. It is not going to be run periodically.

I would need a simple test to confirm that all bits in all bytes are OK without needing to write all possible byte values to every byte.

In run mode I am going to verify all bytes that is written to the flash (read back) so I get a runtime verification that data was stored.

Given that memory, today, is close to zero failure rate, I would just get on with the job and use it, assuming it's working. If you can read/ID the part under SPI that's good enough in my book. Just make sure your timing is within spec.

Then it could be as simple as executing the bulk device erase command, then using your normal FLASH write-with-verify routine to zero each byte. Followed by another bulk erase. Followed with a manual verify that each location was erased. That is assuming your FLASH erases to 0xff. If erased state is 0x00 then manually write 0xff's rather than zeros.

With RAM you might be concerned with one bit affecting other bit addresses, but with FLASH you would wear out the part looking for those situations.

I think its good that you perform this test before shipping product. Expect to find very few failures as FLASH is tested before leaving the factory. Expect most failures will be solder joints, but that doesn't render the test any less valid.

First you should switch the power on.

VLV

|-----------------------------------------------------------------------------| |"Given that memory, today, is close to zero failure rate, I would just get on| |with the job and use it, assuming it's working. [..]" | |-----------------------------------------------------------------------------|

Trends towards lower voltages make resistance to noise not so easy; and smaller feature sizes make single event effects from radiations more likely. I am not so sure that this is as much of a problem for Flash as for RAM though.

True, but you way also want to run a short series of tests designed to locate shorts on adjacent address & data bus lines.

Regards,

On Feb 3, 11:22=A0am, Nicholas Paul Collin Gloucester

It's a worse problem for flash, because the effects while unpowered are just as important as while powered.

But the poster is I think confusing a design qualification test with a factory final test.

Don't tell this to our test engineering department :) Certainly, assuredly, definitely not the case for mass-production consumer electronics. Might be included as a manual BIST step for field diagnosis, but TE's philosophy is that the parts are 100% tested at the foundry and QC escapes at that end can be caught by random QC sampling of final product.

With an SPI-addressed device, you might not have any idea what "adjacent" means for either case. I have seen large SPI flash devices that consisted of multiple cascaded smaller devices, and the internal data width on these devices is unknown or meaningless.

Doh! I missed the whole SPI bit... :(

Regards,