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

Why does MSP430 I2C slave get stuck in STTIFG when external master block reads ?

Vern Yip
Intellectual 810 points

I have an issue that I noticed if I am doing very fast back-to-back write and reads on the I2C.

My MSP430 is always the slave, so there is no opportunity it is master.  However, there are times where, when I "break" my script on the host side (in this case it is a raspberry pi running i2c-tools) and it sends i2c block write/read commands, if I pause my MSP430 code, I see that it gets stuck in:

case  6:                                  // Vector  6: STTIFG
            UCB0IFG &= ~UCSTTIFG;


and the code will just hang/sit at this line of code where it is trying to clear the start flag from the UCB0IFG register.  It seems like the entire bus has hung or something.  The MSP cannot seem to recover. 


I was wondering what is the best way to "reset" the I2C state on the MSP so that it will release the bus and let the master start over?

  • 0
    Genius 4140 points

    Hi Vern,

    That Makes sense to me.

    As you  broke your script (Raspberry-PI) :). It might have struck there. 
    Casuse, in case 6 you donot have any instruction to wake up from sleep mode. 

    also your host is paused there are no TXIIFG interrupts as well where you probably might have had wake up from sleep instruction. and so it is struckl.

    One possible way is to deploy a Watch dog timer in case 6 before you clar flag. check the flag to be cleared in certain time and if not reset or wake up from sleep.
    Cheers.

  • 0 in reply to sri-sri
    Intellectual 810 points

    I see.  I'm using the reference firmware from TI called uscib0_i2c_09.c.  

    Here's my question.  If my hardware does not care about power, can I just remove having to enter low power mode, LPM0 and just stay in regular full power mode?  That way, the program can stay in the main while loop?  I know that sounds bad because it would continuously loop and burn power.  

    But it sounds like to me is that, based on the code, the routine will only exit low power mode, when the stop bit is received, thereby executing __bic_SR_register_on_exit(LPM0_bits0);

  • 0 in reply to Vern Yip
    Guru 227245 points

    Entering LPM is often used for implicit synchronizing the code flow. Besides not  consuming energy for idling around, entering LPM ensures the main execution waits until the ISR signals that it may continue. Simply not entering LPM0 will break such a synchronization and you'll need to introduce a semaphore (a global volatile variable or something similar) to notify main from the ISR that it can continue.

**Attention** This is a public forum