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.

TM4C1290NCPDT: ISR using the SMBUS implementation from TI

Part Number: TM4C1290NCPDT
Other Parts Discussed in Thread: SEGGER

Hi all

I am using the TI SMBUS implementation on a custom board wth a TM4C1290NCPDT. We chose this part due to its large number of I2C controllers. The code runs a FreeRTOS system, and each I2C controller gets its own FreeRTOS task. 

I am using the interrupt driven I2C controller, with my ISR which looks like this

// SMBUs specific handler for I2C
void
SMBusMasterIntHandler1(void)
{
  BaseType_t xHigherPriorityTaskWoken = pdFALSE;

  //
  // Process the interrupt.
  //
  eStatus1 = SMBusMasterIntProcess(&g_sMaster1);
  // handle errors in the returning function
  portYIELD_FROM_ISR( xHigherPriorityTaskWoken );
}

With a copy for each interrupt handler. 

The call to SMBusMasterIntProcess, which is a function from the TI library, I think is maybe not the right way to go. It handles the SMBUS/I2C state machine and it’s a long piece of code (hundreds of lines.) It appears that on occasion the code crashes in the interrupt handler, and I am wondering/worried if the interrupt handler is ‘too long’. I was under the impression that the interrupt handler should be as short as possible and this appears to violate this maxim. Unfortunately when the code gets in this state (not quite crashing but getting stuck) the debugger is of no use (I’m using SEGGER JLINK and it appears to get very confused about freeRTOS sometimes, even though I’m using the FreeRTOS plug in.)

So, my question is, is there anything obviously wrong about my interrupt handler? Should I be doing something else here?  Any words of wisdom ?

Thanks for any guidance

Peter

  • Hi Peter,

       Reading the source code of SMBusMasterIntProcess, I do see the function very long. I think the SMBus stack is based on an interrupt-driven state machine. My feeling is that it wasn't really written with the OS environment in mind or at least not meant to be called directly in the OS-run interrupt handler. I'm not sure if the SMBusMasterIntProcess has taken longer than the OS tick is scheduled. Since I'm not familiar with the FreeRTOS, I can only ask you if you can somehow change the OS tick and see if that will make a difference. Is it possible to not call the SMBusMasterIntProcess in your Interrupt handler? You can use the OS to setup some type of semaphore so that SMBusMasterIntProcess will run as a separate task and pend (waiting) until the SMBusMasterIntHandler1 post a semaphore signal. Again, I don't know the actual semaphore usage and setup syntax using FreeRTOS, it is my understanding of using the general RTOS such as TI-RTOS.  

  • Hi Peter,

        I have not heard back from you. I assume your problem is resolved. I hope my suggestion using semaphore makes a difference to your result. I will close this thread for now. If the issue is not resolved, you can update this post to reopen the thread. 

  • thanks, I did not yet get a chance to delve into this further, but I will pursue your suggestion.

    Best

    Peter