MSP430F4250: EEPROM Return Garbage Value for First 500Bytes

Do you by chance have data sheets for the two variants of the device? I see a "T" model, though it's old (NRND), and I don't see a "K" variant at all.

My first suspect would be page size, though (sample size 3) that appears to be the same for all of them. 

My second suspect would be timing. I notice e.g. that the page write time for the older "R" variant is 5ms, but for the newer "A" variant it's 4ms. Newer devices tend to be faster than old devices, which usually improves (hides) races. It is, however, possible to write code that (accidentally) relies on a device being slow.

How are you checking for write completion? Also, is the threshold exactly/always 500, or just "somewhere around" 500?

Hi Mc,

Thanks for your Response, link for T-Data sheet. I do can't able to find datasheet for K, I'm trying.

1st: I believe we are writing by bytes not by page.

2nd:  EEPROM Code link 

3rd: I checked it multiple times, exactly after 250 samples (500Bytes) I can able to read all samples correctly.

Thank You

Have you talked to the EEPROM manufacturer?

Are these production eeproms, or pre-release samples?

Ya we've spoked with them. Upon there review they couldn't see any problem with the functionality of the chip.

It's a Production Chip. Available in Market.

Then you need to get a scope or logic analyzer and look at the signal interface *very* carefully playing close attention to the datasheet. I would guess that you are reading the data slightly too fast.

Your links don't appear to be working. Could you attach the files instead?

If that's the case after 500Bytes it works correctly. That's confusing again

Sorry for that, Attachment is not working properly. If you don't can you please try the bellow links

DataSheet: 

Code: 

https://1drv.ms/b/s!ArCbXDYx3yjAgRH2BOXkCkPkswkS (CKT)

https://1drv.ms/t/s!ArCbXDYx3yjAgRDGcSp2i2ygU6Ov (CODE)

That is why I think you are right on the edge.

Just to make sure I understand your symptom:

1) If you write 248 samples (496 bytes), starting at address 0, then read them all back, you get incorrect values. (By the way, is there any pattern to the "incorrect"ness?)

2) If you then write 2 more samples (4 more bytes) starting at address 496, then read them all back, you get (all) correct values.

Did I describe that correctly? 

Page boundaries matter even if you're only writing a few bytes. 

Also, where does the checksum fit in?

Yes you are one the point.

both 1 & 2 are right.

The CheckSum is CheckSum = 0xBC

The Data is read from EEPROM and xor'ed with CheckSum before Tx.

I don't see much difference in the two specs. They shortened the glitch filter, such that the older device could have been ignoring some small mistake on the bus and now it isn't -- this is admittedly a long shot.

It also looks like you're not checking for clock-stretching; the data sheet doesn't say it does clock stretching (but doesn't say it doesn't).

A standard experiment at this point would be slowing down the bus -- maybe adding one or more NOPs to your _NOP() macro. Also, as Keith mentioned, a scope is handy for this kind of diagnosis.

The symptom seems to suggest a read failure, rather than a write failure. Do you read all the bytes in a burst, or one at a time?

Write operation is clean and good with 10ms delay, the read is the problem. 

If I'm experiencing this read error for all stored bits adding few _NOP sure makes some sense are even a 10ms delay can also okay as speed is not a demanding factor for me.

This question comes again and again code/ckt/device which works for 15 years down the line, now having error on reading 1st 500 bytes..... lol

I'm not getting sleep some times hahahaha...

Thanks McK, I'll try adding few delay/NOP in read cycle and test them with scope. 

In mean time someone find some bug, please let me know.

Happy weekend all!