• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 51 subscribers
  • Views 1147 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.

RTOS/CC2640R2F: I2C during Interrupt Service Routine

Lukas Hann19
Intellectual 280 points
Part Number: CC2640R2F
Other Parts Discussed in Thread: SIMPLELINK-SDK-SENSOR-ACTUATOR-PLUGIN

Tool/software: TI-RTOS

Hi,

I am trying to use periodic interrupts to generate a signal at set intervals. The periodic interrupts work, but when I try to communicate with an external DAC to generate the signal I run into some problems. I have written a function to send a specified voltage to the DAC, but it doesn't work properly when called from the ISR. I had a look at the signals on a scope and noticed that the i2c communication is much shorter (~150 uS) when the function is called from the ISR compared to when it is run from the main function (~400 uS). Can someone explain to me why this happens and how I can fix it?

Kind regards,

Lukas

  • 0
    TI__Guru** 105180 points
    Hello Lukas,

    Performing operations in an ISR is going to have shorter latency as compared to scheduling a RTOS task, however the former has the potential to negatively interfere with other real-time operations. I suspect that is what is happening here. I suggest looking at the SIMPLELINK-SDK-SENSOR-ACTUATOR-PLUGIN for reference examples for working with I2C.

    Best wishes
  • 0 in reply to JXS
    Intellectual 280 points

    Hi,

    Thanks for your reply. I also thought that the RTOS might be cutting off the I2C communication, so I had a closer look at the scope traces. When calling my function from the main loop, I get the expected communication:

    0x98 (addr. is 0x4C + write bit), 0, (ack), 0x10 (control byte), 0 (ack), 0x7F (frist data byte), 0 (ack), 0xFF (second data byte), 0 (ack).

    However, when calling my function from an ISR, it is not a truncated version of that communication but something seemingly random. From my observations, one of 2 things occurs. Either:

    0x22 (addr would be 0x21 + write bit), ack, 001 (binary) 

    and then cut off, or:

    0x21 (addr woul be 0x20 + read bit) and then the clock line stays low for what would be another 4 pulses before going back high.

    So clearly the I2C line isn't just being cut off, it is just transmitting nonsense. Can you think of a reason this might happen in an ISR but not in the main loop? Can the I2C bus just not be used inside an ISR?

    Kind regards,

    Lukas

  • 0 in reply to Lukas Hann19
    Intellectual 280 points

    Update:

    I was using the I2C in blocking mode, and blocking functions are not allowed during interrupts which caused the problem. I still don't understand why the first few bits were sent, but when using callback mode it works. However, there are problems if the I2C transaction doesn't finish before the ISR (because in my case the I2C_Handle and I2C_Transaction are local variables to the ISR).