EmbeddedRelated.com
Forums

Programming a self test for a SPI FLASH memory?

Started by sima February 3, 2009
Hello

I need to program a self test for a SPI FLASH memory in an embedded system.

How should I do that.

Should I first erase the memory (sets all bytes to 0xFF), then write 0x00 to 
all bytes, verify, then erase, verify that all bytes are set to 0xFF again?

Any tip on how I should do?



sima" <sima@nospam.se> wrote in message 
news:49880421$0$90264$14726298@news.sunsite.dk...
> Hello > > I need to program a self test for a SPI FLASH memory in an embedded > system. > > How should I do that. > > Should I first erase the memory (sets all bytes to 0xFF), then write 0x00 > to all bytes, verify, then erase, verify that all bytes are set to 0xFF > again? > > Any tip on how I should do? > >
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. -- Regards, Richard. + http://www.FreeRTOS.org Designed for microcontrollers. More than 7000 downloads per month. + http://www.FreeRTOS.org/Documentation New FreeRTOS eBook - learn how to use an RTOS.
"FreeRTOS.org" <noemail@given.com> wrote in message 
news:gm933b$30n$1@news.motzarella.org...
> sima" <sima@nospam.se> wrote in message > news:49880421$0$90264$14726298@news.sunsite.dk...
> 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? >
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.
>> >> How often is the test to be performed? >> >> + Continuously. >> + Periodically. >> + On start up? >> > > 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.
sima wrote:
> > 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.
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.

sima wrote:

> Hello > > I need to program a self test for a SPI FLASH memory in an embedded system. > > How should I do that. > > Should I first erase the memory (sets all bytes to 0xFF), then write 0x00 to > all bytes, verify, then erase, verify that all bytes are set to 0xFF again? > > Any tip on how I should do?
First you should switch the power on. VLV
On 2009-02-03, TTman <someone.pc@ntlworld.com> wrote:

|-----------------------------------------------------------------------------|
|"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.
David Kelly wrote:

> 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.
True, but you way also want to run a short series of tests designed to locate shorts on adjacent address & data bus lines. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266
On Feb 3, 11:22=A0am, Nicholas Paul Collin Gloucester

> 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
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.
On Feb 3, 10:03=A0am, David Kelly <n4...@Yahoo.com> wrote:

> I think its good that you perform this test before shipping product.
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.