• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 80 subscribers
  • Views 1763 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

I2C problem with FRAM -Device address

Shailesh Chaudhary
Prodigy 210 points
Other Parts Discussed in Thread: MSP430F2616

Hello,

I'm using MSP430F2616 and found it as best option for my project. ADC, DAC, UART and all other peripherals working fine with micro controller. I tried to interfaced FM24CL16B FRAM with MSP430F2616 on I2C bus (only single slave & single master on bus). For slave address i passed "0xA0" (1010 0000) it does not acknowledged, but when i passed "0x50" it acknowledged and working fine for read and write without any problem.

any one experienced this type of problem with MSP430F I2C?

Is there any problem with MSP430F2616 or FM24CL16B?

  • 0
    Prodigy 210 points

    Is this problem regrading bigendian or littlendien ?

    Is there any setting in compiler?

  • 0 in reply to Shailesh Chaudhary
    Prodigy 210 points

    Is there any one who can discuss/solve my problem?

  • 0 in reply to Shailesh Chaudhary
    TI__Guru 64600 points

    Shailesh Chaudhary said:

    Is there any problem with MSP430F2616 or FM24CL16B?

    No.  This is expected behavior based on information contained in the MSP430x2xx Family User's Guide (SLAU144) which describes the functionality of the USCI peripheral in I2C mode.  Please review the register description of UCBxI2CSA in Section 17.4.9.  This User's Guide is available on the MSP430F2616 Product Folder.

     

    Shailesh Chaudhary said:

    Is this problem regrading bigendian or littlendien ?

    No.  Please review the MSP430x2xx Family User's Guide (SLAU144).

     

    Shailesh Chaudhary said:

    Is there any setting in compiler?

    No.  Please review the MSP430x2xx Family User's Guide (SLAU144).

  • 0 in reply to BrandonAzbell
    Prodigy 210 points

    Thanks BrandonAzbell.

    Now i am able to understand reason behind working of FRAM with device address "0x50".

    Now i have decided to use I2C LCD controller (2 salve on bus FRAM & LCD controller) whose address is "0x70". I loaded "0x38" and its working fine.

    Can you please suggest how to switch between 2 slaves?

    Is there any specific sequence to load slave address in UCBxI2CSA? or i can write UCBxI2CSA any time.


  • 0 in reply to Shailesh Chaudhary
    TI__Guru 64600 points

    Yes, I would say that the time to update the UCBxI2CSA register is after each transaction is completed.

  • 0 in reply to BrandonAzbell
    Prodigy 210 points

    Thanks BrandonAzbell.

    You mean no need to set UCSWRST and then clear it, or any sequence. I can write/load new slave address to UCBxI2CSA register when transaction with  one slave completes. No other register status checking?

  • 0 in reply to Shailesh Chaudhary
    TI__Guru 64600 points

    I wouldn't say you should not check status.  There is some description of the procedure in the MSP430x2xx Family User's Guide in Section 17.3.4.2 describing I2C Master mode operations.

    Also, there are some very simple code examples available on the MSP430F2616 Product Folder in the Software & Development Tools section to review.

  • 0 in reply to Shailesh Chaudhary
    Guru 227245 points

    You figured it out yourself, but for completeness:

    An I2C address is either 7 or 10 bit. Most manufacturers, however, list their device address as 8 bit value, already containing the R/W bit. In this case, usually, two addresses are given, one woiht LSB clear for write and one with LSB set for read.
    The MSP, however, only needs the upper 7 bit (right-adjusted) as slave address and adds the R/W bit automatically, based on UCTR.

    For addressing different slaves, it should be sufficient to change teh I2CSA register to the new address before starting the next transfer. This should only be done after the curent transfer has been completed (so don't just change the addressand set UCTXSTT to start the next transfer after the current is finished. THis won't work and probably the old address will be used.
    The users guide recommends configuring all USCI registers (except the transfer control bbits, of course) with UCSWRST set. It ensures that the USCI starts the next transfer with the updated settngs adn the state machine isn't confused. However, I doubt this is really necessary for a slave address change. (for a baudrate change, it definitely is)
    Well, doing it with SWRST ensures that the last transfer has definitely ended (even if prematurely forced so) before the change is applied. :)

**Attention** This is a public forum