• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 80 subscribers
  • Views 132 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.

Original question:

MSP430G2553: USCI module during sleep

MSP430G2955: USCI module in slave mode

Patel Jignesh
Intellectual 420 points

Part Number: MSP430G2955

Hi All, 

I have msp430g2955 and I have implemented firmware that work as I2C slave mode with all things works fine like register set and get working fine..

Only issue that I am facing like on long run whitout accessing this slave I notice msp430g2955 take SDA lines low.. So does we have any limitation of USCI module we have that it pull SDA line low and second things that how I can detect such situation.

I can not check UCBBUSY condition because I am slave and master might be calling me so I am not sure like actually using it or not.

Please help me if we have some workaround or solution possible here.

  • 0
    TI__Genius 15051 points

    Hi Patel,

    • If reset MSP430G2955, will this issue be solved?
    • How long no access to MCU will cause MSP430G2995 to pull SDA lines low? And is there any other slaves in the bus?
    • You mean SDA low, is this only happens during Host send clk or always low in bus.
    • Is this issue happening when you flash demo code in our SDK?

    Regards,

    Zoey

  • 0 in reply to Zoey Wei
    Intellectual 420 points

    yes reset MSP430 solve issue.

    it pull SDA permanent do we have any seting we can add timeout and if timeout happen reset usci module of we can get information in firmware ?

    SDA low meaning bus low so other slave also not able to accessible.

    We are not using demo but code is very simple like demo code of i2c slave

  • 0 in reply to Patel Jignesh
    Guru 103065 points

    This condition (SDA low but not SCL) is not normally the fault of the Slave. Indeed, I can't think of a way for a Slave-side USCI to unilaterally generate this symptom. Most often it's caused by the Master (Master-Receiver stops sending clocks in mid-transaction) or by noise on the wires generating extra (false) clocks.

    The condition would normally be detected and fixed by the Master, using the "9-clocks trick" or by (remotely) resetting the Slave, but it sounds as though you have no control over the Master side.

    The USCI doesn't have a timeout mechanism (even the eUSCI in the FRx series can only time out on SCL). The only thing I can think of for the Slave is a periodic timer and a variable with an "active" indicator plus a transaction counter: If those values are the same for two consecutive periods, that probably indicates a hang. Of course you'll want to keep the polling period fairly long to avoid false positives. I haven't tried this, but it might work.

**Attention** This is a public forum