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.

Issues with the I2C driver on CC2640 custom board Transmitt never finishes

Hi there,

I am using TIRTOS 2.28.03 and the program gets stuck at this point

I followed and have double checked the guide to include the I2C driver, but can't find any mistake. It looks good and as described.

And from the comments, the software should not stall at this point. But the whole device is blocked waiting for the flag to clear.

I must say that this occurs on a new custom board where I have not managed yet to get I2C running. However, even it is a hardware problem and the slave device does not respond, the software should never block just because any I2C chip connected gets out of function.

What could I have overseen ?

Thanks in advance

  • Ralph Deffke said:
    And from the comments, the software should not stall at this point. But the whole device is blocked waiting for the flag to clear.

    I'm not sure why you say that the SW shouldn't stall at this point.  The line you highlight is supposed to block, waiting for the corresponding Semaphore_post() which occurs in I2CCC26XX_blockingCallback().

    Ralph Deffke said:
    the software should never block just because any I2C chip connected gets out of function.

    The SW needs to block while waiting for the I2C transfer to complete.  If the I2C is not functioning correctly then I2CCC26XX_blockingCallback() will never get invoked.  Or am I misunderstanding your statement/question?

    Regards,

    - Rob

  • Hey, come on, the TI ! comment above says clearly "... I2C HWI will unblock upon errors "

    Most common error is time out. It is fact that any blocking from a simple communication is not acceptable.

    Also I want to know what I have to do that this blocking is handled.

    Any industrial control system should not use TIRTOS I2C driver then.
  • Ralph,

    We have an enhancement request to add a timeout into the I2C driver.
    TIDRIVERS-131: I2C driver needs a timeout feature

    It has not been committed to a release yet.

    Instead of I2C_MODE_BLOCKING mode, you can use the I2C_MODE_CALLBACK mode when you call I2C_open. This allows you to manage the timeout yourself.

    Please note the blocking is not a polling. TI-RTOS is a preemptive RTOS. An active thread can only be preempted by
    1. a higher priority thread becomes available
    2. it calls a blocking call (e.g. Task_sleep, Semaphore_pend with a non-zero timeout, etc.).

    If Semaphore_pend (with a non-zero timeout) is called and not available, that Task is blocked and other tasks (of the same priority or lower) are allowed to run if they are in the ready state. If there are no threads ready to run, for devices with power management (and it's enabled), the device will go into the appropriate low power mode.

    Todd

  • Thanks Todd for your professional advice on this issue.

    And good to know that it is in focus