larwe wrote:

> With an SPI-addressed device, you might not have any idea what
> "adjacent" means for either case. 

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

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, 7:19=A0pm, Mark McDougall <ma...@vl.com.au> wrote:

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

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.

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.

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.

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 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.

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

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.

>>
>> 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. 

"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.