MSP430F4250: EEPROM Reading Wrong Data

While there was no solution, we pretty much exhausted our ability to help last time. Is there new information?

I tested the EEPROM completely. I've improved the functions for I2C Start/Stop/TxACK, the last code doesn't had practice of NACK so I've introduced that now.

When I do work only with EEPROM(T-chip/NEW) and  MSP430F4250 for reading and writing, everything worked. But still with the old code nothing changed. 

We are on the path to narrow down that MSP is overwriting it's RAM, but I'm not sure.

I've made sure EEPROM works fine, Comms works fine. Data write works fine.

To be even more precise:

If you see the code there is function called "Start_The_Logger" where MSP reads a settings Byte from EEPROM which is 0x38 (0011 1000, as per the settings byte the MSB is responsible for C/F if 0 start the logger as C if 1 start the logger as F) so the logger should start with C in this case, but it starts as F.

CrossWorks for MSP430  is used for compiling the code. The EEPROM read behaviour of MSP is different when it runs on Debug/Release models.

in Release Reading on Byte is also wrongly interpreted, where in Debug all one byte Read interpreted correctly. but when it come to huge data read the real scenario starts again.(if the read is less than 500 bytes read is interpreted wrongly where if the read is more  than 500 bytes all are read correctly. Actually this point is a validation for write works. (It is storing the data correctly)

Hi Sivashankar,

I read through this and the previous post to get an understanding of the issue.

My first thought is since you are able to read/write correctly larger number of values (500), then I would rule out the MSP430 silicon.

There could be possibly something in your code.

Next, since the problem occurs with the new EEPROM, I would suspect not a timing issue, rather something in the internal addressing of the EEPROM.

Let me look through the data sheets and see if there is something that is being overlooked.

One think you can try is, reduce the code to the absolute smallest possible but still demonstrates the issue.  In the process you may discover the issue plus you can post for me to review.  But please, this must be the absolute minimal amount of code necessary to demonstrate the issue.  I'm talking 100 lines or less.

Hi Sivashankar,

I can't seem to find datasheet for older _K device so I don't know if there were any possible changes in the chip's timing compared to _T.

Have you made any progress on your end?

Hi Dennis,

Was really happy after your response. I'm on my way developing a short 100 line code to demonstrate the problem. 

Regarding the old data sheet, I'm even not sure but I have a report from ST on comparing the both. PFA

C - Click 'C' to download

I had to dig back in time to find something resembling your code. I see at least the potential for problems in the bit banged code to read  a byte.

You set the clock output high and then read the data. The delay here is a bit fuzzy owing to the complicated expression in the next line but it wouldn't be hard to exceed the data hold time specification of the EEPROM.

About the minimum you could realize is two clock cycles (read using address already in register) and at 8MHz that exceeds the specification so the data might already be gone. You might want to examine the code the compiler produces to see what the delay really is.

You also need to worry about the access time. How long does it take to get from where you set the clock low to where you sample the data?

I vaguely remember doing some I2C via bit banging and it was mostly about making sure I satisfied all of the required timing limits.

Scratch the data hold problem. It has been too long since I dug down deep into I2C and I mixed up the edges. But you do have to worry about access times.

Dear Dennis and David

On my way of developing the 100 line code I found a bug in EEPROM state going from set_to_read condition to stop condition and without getting any data. after commenting the stop condition things seems to work.

So practically my problem solved. 

But still, have a question how it worked with EEPROM- type 'K' and not with EEPROM-type-'T'

Keeping all things aside, I wanna Share a big thanks for everyone who jumped in and helped us on the way. Each point has opened up different dimension and it was a great learning for me personally. 

Now the question inside me is how the  EEPROM- type 'K' (old) has tolerance to work even with a wrong EEPROM state where the new  EEPROM- type 'T' (new) is so sensitive for this EEPROM state.

Kind Regards, 

Sivashankar

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

after changing

Line No: 2339:------>"      Stop_EEProm(); // Terminate the data byte/bytes, Reading"

to:------>"  "if(Full != 0) Stop_EEProm(); // Terminate the data byte/bytes, Reading"

Bug Fixed

It is difficult to follow your code in part because it is one huge blob. I have taken advantage of separate compilation to split my code into independent parts for a long time now. This makes things a lot easier to maintain and I can make sure that changes in one place do not accidentally affect something else. It also makes compiling after a change a lot faster since not as much code has to be processed. Not as big a deal now as when my code resided on floppy disks.

As an example, I dug up my old bit banged I2C code and that was in the file i2c.c. Which was used by lsm303.c which dealt with a sensor. (In i2c.c I use the preprocessor to define symbols to manipulate the clock and data lines so I don't have to remember which port and pins are used and to make changes a lot simpler.)

A couple of things I did notice is that it appears that you do not NACK the final byte of received data but instead just do a stop and you do not support clock stretching. You might get away with that for now.