0

We've been using MSP430f4250 in a product for Temperature data logging which is successful in market for last 15 years. It's been working with STM 24C64RP_K very well. Recently we have changed the STM24C64RP_K(old) to STM24C64RP_T(new) and observed that MSP is reading data wrongly from EEPROM. At the begging we thought that the problem is due to EEPROM as that's the only change happened. We spoke with ST and double checked the new EEPROM is working well and we tested it in house and made sure the ST review. We are bit confused in the point why MSP is reading data wrongly from new EEPROM whereas it's been reading data from the old EEPROM for last 15 years correctly. We where been using the new EEPROM with same circuit and firmware which we where been using with the old one. One clear thing we observe was Write cycle is working properly, where read cycle isn’t. Any recommendations to solve this problem.

Note: The MSP430f4250 is highly used FLASH: 89% and RAM 76%(only 0.1KB is left). We suspect RAM overflow happens.
STM24C64RP_T(new) Study Report: https://1drv.ms/b/s!ArCbXDYx3yjAgQ_7dKTv5eoTe4Wx?e=nIExgQ
Code : https://1drv.ms/t/s!ArCbXDYx3yjAgRDGcSp2i2ygU6Ov?e=yrkJWa
CKT: https://1drv.ms/b/s!ArCbXDYx3yjAgRHEtZEFOuZ1jOaq?e=UM1pS0
Detailed Report: https://1drv.ms/b/s!ArCbXDYx3yjAgRv0BxxOXU13ORfd?e=x5Cukj
Siva
  • 37
  • 4
  • 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. – Siva Nov 19 '20 at 08:42
  • 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. – Siva Nov 19 '20 at 08:43
  • 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) – Siva Nov 19 '20 at 08:43
  • This might be an electrical problem, in which case the question is off-topic here. If it is a programming problem, create a *minimal* program that shows how you read a byte from the EEPROM, and include it in the question. (To edit, click "edit".) – CL. Nov 19 '20 at 15:39

1 Answers1

0

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.

Siva
  • 37
  • 4