• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 79 subscribers
  • Views 2613 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

source code for interface to Microchip I2C EEPROM 24AA02 using the USI port on a MSP430G2402

Ketan Mehta
Prodigy 120 points
Other Parts Discussed in Thread: MSP430F5438A, MSP430G2402

Hi All,

Will greatly appreciate if someone can provide some references where I can find source code to read the Microchip 24AA02 EEPROM. I need code that works with the USI on the MSP430G2402. Already have I2C stuff working that uses the USCI on a MSP430F5438A. Specifically need code that uses the USI on the G2402 for the Microchip EEPROM 24AA02.

I have been debugging some code that I derived from the example project "msp430g2xx2_usi_06". I can see the ACKs from the 24AA02 for the address and read commands. But all data bytes that I read from the 24AA02 come back as 0xFF. Any suggestions as to why I only read back 0xFF will be appreciated.

Thanks in advance.

  • 0
    Guru 25210 points
    >Any suggestions as to why I only read back 0xFF will be appreciated.

    Just to get the obvious question out of the way.... Are you sure that there is data programmed into the EEPROM and it's not blank?

    Other things to check...
    Have you looked at the I2C transactions with an oscilloscope to see what the EEPROM is sending?
    Also, double check that the correct information is being sent into the EEPROM (device address, memory location address, etc) using an oscilloscope?
    Does that device require a repeated start sequence?
  • 0 in reply to Brian Boorman
    Prodigy 120 points

    Brian,

    Certain that there is valid data at the location I am trying to read. Reading addresses 0xFA though 0xFF (six bytes) which have the manufacturer code and a unique ID lasered into the EEPROM.

    Have verified that the data getting written to the slave EEPROM is correct. For example, first I write a 0xA0 to tell the eeprom that I am going to perform a write operation. Then I write the address byte 0xFA to set the eeprom's address register. I receive ACKs for both bytes from the eeprom. Then I write the command 0xA1 to the eeprom to tell it that I want to read data. Again I receive the ACK bit from the eeprom. Finally I read in 6 bytes. But all six bytes come in as 0xFF.

    I have tried two different boards thinking maybe the eeprom part on one was bad. Second board behaves exact same way.

    Any thoughts/suggestions?

  • 0
    Prodigy 120 points
    Solved the problem by bit banging it in software. Painful but I think it was necessary because there seems to be some basic mismatch between the Microchip and TI implementations of I2C. Tried practically every combination/option to use the USI and was unsuccessful. Wish I had gone straight to doing my own I2C comm software implementation instead of trying to use the USI in I2C mode. Would have saved myself a lot of time.

    This experience brings up a point about the example projects provided by TI. In general they are very useful. But the I2C examples in this case were useless because they all assume the two communicating devices are both MSP430s. I wonder if TI is testing its I2C implementation with third party devices or not. If not, that would be a fairly serious shortcoming IMO.
  • 0 in reply to Ketan Mehta
    Guru 25210 points
    Many people use the MSP430 to talk to other I2C devices, so I would be hesitant to make any statement that the USC/USCI peripherals in I2C mode have fundamental flaws. There are literally millions of these things in all manner of fielded products, from commercial to industrial, automotive, and military.

    I've used the I2C in production designs to talk to peripherals such as EEPROM, MEMS compasses, and SMBus gas gauges, so I know that it works.

    I will agree that some of the examples provided aren't the best. They tend to use polled-mode coding instead of interrupts. The reason for some of the examples being used to talk MSP to MSP is that for the hobbyist or university student having a couple LaunchPad boards isn't an unreasonable expectation. Otherwise, what peripheral would you choose and have a reasonable expectation that a lot of people have access to?
  • 0 in reply to Brian Boorman
    Prodigy 120 points
    Definitely agree that TI's I2C implementation must be working in the vast majority of cases. I have myself gotten it to work on a 430F5438A USCI port with a eeprom. But the problem started for me with the USI port on a G2402. And I am not saying TI's implementation is buggy. I said there may be a mismatch between Microchip and TI implementations (and more specifically when using the USI port on a G2402). Did not claim that there is a "fundamental flaw"; just said there MAY be a mismatch. And I say that only only because I truly did try all logical variations of setup/programming the control registers and just could not get it to work. Don't know for sure if I am missing something; or is the problem on the Microchip side;or is it on the TI side. Most likely I missed something (but cannot figure out what could it be because I went through all options very methodically). Also, the fact that I was able to get it to work with my own code proves that I do understand the I2C protocol.

    Agreed that there are too many devices out there to test with all of them. But I do have an expectation that TI would test with at least a few other third party devices (TI could pick the five most popular commercially available devices).

    Anyway, still like the msp430 platform very much and appreciate all the support provided by TI.
  • 0 in reply to Ketan Mehta
    Guru 227245 points
    The USI is not much more than a shift register with baudrate generator. So implementing I2C on it is, well, challenging. But definitely possible and people have done it successfully in the past.
    I don't know whether there is a I2 demo code available for this processor. If not, then try to find code for other processors with USI. There are some. However, going for real I2C support with an USCI module is by far the better option. Even the cheap G2553 has one.

**Attention** This is a public forum