• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 1152 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.

CCS/MSP430F5514: I2C Driver Lib Timeout Value

Gerry Kurz
Intellectual 685 points

Part Number: MSP430F5514

Tool/software: Code Composer Studio

I am using the MSP430F5xx_6xx_DriverLib version 2_91_03_00.

Some of the USCI_B_I2C routines have a timeout value. What would be a good setting for this value using 400 kHz bus speed 7 bit addressing?

Also, it seems that the routines do not check for a non_acknowledge condition. Is this somehow handled with the timeout?

  • 0
    Intellectual 685 points

    Part Number: MSP430F5514

    Tool/software: Code Composer Studio

    Using MSP430F5xx_6xx_DriverLib Version 2_91_03_00

    USCI_B_I2C_masterReceiveMultiByteNext function does not wait for UCRXIFG as USCI_B_I2C_masterReceiveSingle does and therefore returns invalid data.

    Same problem with USCI_B_I2C_masterReceiveMultiByteFinish and USCI_B_I2C_masterReceiveMultiByteFinishWithTimeout

  • 0 in reply to Gerry Kurz
    TI__Guru 56685 points
    Gerry,

    I've merged your two threads as they are similar in subject.

    For Timeout, this is a value of time that is acceptable for your application to be stuck checking for an action without doing anything else. the timeout is a way out of an infinite loop that is polling a flag., in this case the RXIFG. In some cases, such as the STOP with Timeout, the timeout is set for what the maximum time you want to wait for a stop condition after being issued.

    Yes, you are correct that these functions do not handle NACKs.

    Most of the routines check to see if you are using interrupts, if so it does not check for the associated flag as it assumes you are using the API within the correct interrupt case, such as USCI_B_I2C_masterSendMultiByteStopWithTimeout() . The functions with timeout will use the timeout value in conjunction with polling IFGs for a max wait time, such as USCI_B_I2C_masterReceiveMultiByteFinish(). the timeout basically allows you to jump out of possible infinite loops if your I2C timing of interrupt flags is off.

    the functions you pointed out seem to fall in one of the categories above, with the exception of USCI_B_I2C_masterReceiveMultiByteNext(). this function just reads the RX_BUFF. It is assuming that since the master is in RX mode, you are using interrupts and the function should be used in the appropriate interrupt case in the ISR. It looks like most of the RX APIs are built in a similar manner.

    For additional I2C debug, please see the following application note: http://www.ti.com/slaa734
  • 0 in reply to Jace H
    Intellectual 685 points
    Hi,
    I was thinking more of the minimum timeout value that would not affect the transfer.
    And yes, my application is not using interrupts, so I see now that the routines that do not poll will not work.
    It would be helpful if this was pointed out in the documentation.
    As a general comment, the documentation for this particular API (I2C) is not very good.
    Overall, the driver lib is very good and pretty well documented, however the I2C API is not.
  • 0 in reply to Gerry Kurz
    TI__Guru 56685 points
    Gerry,

    I agree with you about the state of DriverLib functions for I2C and other comms. Personally, I do not use DriverLib for communications as I prefer the control of register level. What i do find DriverLib really useful for is initial setup of peripherals, such as the SVS/PMM and other complicated peripherals.
  • 0 in reply to Jace H
    Intellectual 685 points
    Yes I will likely write my own later but the driver lib is handy to get things going quickly

**Attention** This is a public forum