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.

MSP430G2402 USI SCLK low

Other Parts Discussed in Thread: MSP430G2452

I can not seem to have the SCLK signal held low when operating in the slave I2C mode. The I2C communications run fine, but I need to introduce a SCLK clock stretch when 'reading/writing' data. After detecting the read operation, where I set an external 'process state' to handle the reading of the appropriate data, the SCLK is held low until I execute the 'USICTL1 &= ~USIIFG' line the clock line is released (returned high). How do I keep the clock low until I reload the USICNT register?

case XMIT_DATA: // Check ACK and send next byte

    if (USISRL & 1) { // Check if NACK

          u8_USI_InterruptState = WAIT_START;

     }

else {

       u8_USI_ProcessState = READDATA;    // a read request, do not load USICNT

}

break;

case XMIT_DATA_ACK:           // Setup to Receive ACK

     USICTL0 &= ~USIOE;                             // SDA = input

     u8_USI_InterruptState = XMIT_DATA;   // On next CLK\ check ACK & setup for reading next byte

    USICNT |= 0x01;                                     // Bit counter = 1, receive Ack

    break;

}

USICTL1 &= ~USIIFG;                             // Clear pending flags

}

 

  • Hi Tom,

    From the 2xx user's guide section 14.2.4.2:

    "In slave mode, SCL is held low if USIIFG = 1, USISTTIFG = 1 or if USICNTx = 0".

    Is USICNT = 0 before you are re-loading it?

    In addition, it also sounds like from section 14.2.4.3 - I2C Transmitter - that writing into USICNTx will also clear USIIFG and release SCL:

    "In transmitter mode, data is first loaded into USISRL. The output is enabled by setting USIOE and the transmission is started by writing 8 into USICNTx. This clears USIIFG and SCL is generated in master mode or released from being held low in slave mode"

    I think this would mean that you should not have your software clear USIIFG, but instead just reload the count which should do the reload you are asking about as well as clearing USIIFG for you and releasing the SCL line only after the USICNT load has happened.

    Hope this helps!

    Regards,

    Katie

  • Hi katie - I tried just about every combination of not loading the USICNT (yes, it was 0) etc. No matter what I did, if I clear the USIIFG flag, or even if I disable the USII interrupt the SCL line would be freed. I finally resorted to a brute force approach where I took the SCL line out of USI mode (clear the control bit) and forced it into being a straight DOUT (preset to 0) and then exited the interrupt routine. After loading data etc I re-enabled the SCL line to be in  the USI mode that let it get released. A very convoluted approach...

    Thanks for the response... there maybe some magic flag bit somewhere that would have the USI behave as the manual suggested, but I haven't found it (tried on 2 different variants of chips...)...

     

    tom

  • Tom,

    I made a USI library on MSP430G2452 sometimes ago and you can find it here:

    http://processors.wiki.ti.com/index.php/I2C_Communication_with_USI_Module

    just wonder whether you have looked at it.

**Attention** This is a public forum