A very hard problem for me. FLASH ROM write fail!

Hi All, If your FLASH rom sometimes will write wrong data, how will you debug it?

The firmware was used for a long time........with no problem..

We got some flash rom data have regular difference ( for example, if the update data is 0, but the flash save data is 3, if the update data is 2, but the flash save data is 5), but some part/secotr they are all correct, but some part they are all wrong, what I can sure is the data on the begging has regular difference.

Could you please adivce? I don't know how to debug it....

Thank you very much..

Best regards, Boki.

We didn't encounter this problem when we are in design phase, on mass production phase, we got this problem, and it is very hard to debug, because some FLASH rom fail and some not, the H/W,S/W are both the same... I still don't know that is a S/W or H/W problem now...

Another problem is I can't guarantee every FLASH rom will fail after N times upgrade. Sometims I guess that is a FLASH manufacture problem, but I know that is almost impossible.

Our programmer is control by embedded system CPU/firmware.

I have no chance to changed ROM manufacturer...

If the ROM is programmed > > Hi All,

When I check the fail Flash rom,

Correct data:

01 02 03 04 05 06 07 08 09 00 ....

Flash rom data:

06 02 07 04 09 06 0B 08 09 00 ....

Another Flash rom data:

16 02 17 04 19 06 1B 08 19 00 ....

It seems that have a rule, but I can't see the rule between different fail Flash roms....

and some data block are all different ( don't know, just random different )

Is that a HW or SW problem ?

Best regards, Boki.

but

has

We need to know what part and manufacturer you are using and what you use to program it. How often does a ROM show an error ? If a part is not programming correctly, you are looking at a poor quality batch, or trouble with timing, programming algorithm or voltages.

To isolate the cause, you often have to change things out until the problem goes away -

- A basic step is to find if the fault isin the ROM part itself, or the programming hardware?

- If you use a programmer, buy, rent or borrow another programmer and see if that solves the problem.

- If you have changed ROM manufacturer, can you try some of the parts you used earlier, or another manufacturer ?

- If the ROM is programmed inside your product, has your product changed ?

Roger Lascelles

How come the first 5 odd numbered bytes are correct? Address bit funky? Is it a serial access device? Parallel? If a serial device, I would suspect a software error. Parallel could be either (or both). Are you dealing with timing requirements correctly? Looks software buggy to me. GG

Boki, Is this by chance a 16bit Flash part? - is appears all your odd bytes are corrupted.

If it is a a 16bit flash part then I have seen this behaviour before, it occurrs during the write when you only test for the 'end of write' on the high order byte status.

Any chance you can provide the flash part number?

Heath

You *NEVER* do ! It's called Sod's Law.

Likely causes may include operating the parts at or near to any specification limits, manufacturing tolerance spread related issues and just even a 'duff' batch of parts. It *does* happen sometimes !

Have you tried equivalent parts from several manufacturers ? Have you even tried a batch of parts from the same manufacturer but with a different batch / date code ?

These are things you have to do to help resolve such issues.

Is the Flash memory updated in-system on a regular basis ? I assume that's what you mean.

Ohhh - and if so - a classic issue is the following one. What happens if someone powers down the product in the middle of a write cycle ? Have you addressed this possibility ? Which reminds me - I ought to check that I did that in one of *our* products !

Graham

Something like:

29LV160TB/TC

"Mr Rogers" ¼¶¼g©ó¶l¥ó·s»D:1120068543.2429179868018a2e4869f88036e077af@teranews...

Yes, of course, that will be a problem.

The CPU base code will read flash's data (firmware) to startup.

I have no enough time to program our chip to support upgrade in any situation, but I knew it will be a problem. What I can do is to remider user do not remove power when he/she is doing upgrade.

Best regards, Boki.

Serial, Parallel is good point.

but we are using parallel.

I think timing is ok for circuit, because I try about 100 times on some other PCB, they never fail...

I have tried re-program a fail FLASH rom, and then install them back to PCB, they work very good..........

Sounds like Atmel ATMega 32 or 128 AVR parts to me...

boB

Which gives *zero* hits on Google.

You could try a little harder Boki, to give us some information to work on !

It aint AMD or Atmel apparently.

And ALSO.

Please stop writing your reply at the *top* !

Good newsgroup practive is to post your answer at the bottom so it's clear what is the question and what is the answer. Also please don't 'snip' i.e. remove all the previous poster's text. It makes it all but impossible for anyone to understand your line of thought.

Graham

Hi, Graham,

MXIC

Sorry about *top *bottom problem, it seems to be MS outlook express problem, sometimes I just reply it directly..., now I will reply by google.

*For other reader,I am not saying MXIC FLASH has problem, this is for discussion only.

The compiler pass the upgrade routine , so I think the memory allocation is no problem.

Am I right?

Thank you very much.

Best regards, Boki.