• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 761 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.

Original question:

TMS570LS1115: I2C Interrupt not working

TMS570LS1115: Understanding I2C interrupt

Pradeepa Senanayake
Intellectual 715 points
Part Number: TMS570LS1115
Other Parts Discussed in Thread: HALCOGEN

Hello,

I'm working with I2C interrupts and I would like to clarify few things.

If I transmit a 3 bytes of data over I2C, how many TXRDY interrupts will I receive? 

My understanding of the operation after going through the datasheet was,

  1. Copy byte 1 to I2CDXR -> I2CDXR gets transferred to I2CXSR -> #1 TXRDY interrupt
  2. Copy byte 2 to I2CDXR -> I2CDXR gets transferred to I2CXSR -> #2 TXRDY interrupt
  3. Copy byte 3 to I2CDXR -> I2CDXR gets transferred to I2CXSR -> #3 TXRDY interrupt

Ideally I should be receiving three TXRDY interrupts. This was what I was expecting.

However, the way the TI libraries handle this condition is different. It is written in such a way that it only needs (Data length - 1) number of interrupts to send all the data. 

If I may go through the function call sequence of TI library,

  1. Data submitted through i2cSend (Data length 3)
  2. This will copy the first byte to the I2CDXR and enable interrupt
  3. Upon the h/w interrupt, i2cInterrupt function will get executed (1st byte transferred to I2CXSR)
  4. This will copy the second byte to the I2CDXR
  5. Upon the second h/w interrupt, i2cInterrupt function will get executed (2nd byte transferred to I2CXSR)
  6. This will copy the third byte to the I2CDXR
  7. Then strangely enough, the function will disable TXRDY interrupt

I commented the TXRDY interrupt disabling code, but still I could not receive the third (missing) interrupt.

Please help me understand the sequence as it is affecting our product heavily at the moment.

Thanks!

  • 0
    TI__Guru**** 199096 points
    Hello,

    The TXRDY is Generated when the transmitted data has been copied from the data transmit register (I2CDXR) into the transmit-shift register (I2CXSR).

    But in the HalCoGen generated driver, the last transfer (DXR-XSR) doesn't generate interrupt, it will jump to notification for processing.
  • 0 in reply to QJ Wang
    Intellectual 715 points
    Hello,

    I think the specified behavior is achieved by the following code segment

    if (g_i2cTransfer_t.length > 0U)
    {
    i2cREG1->DXR = *g_i2cTransfer_t.data;
    /*SAFETYMCUSW 567 S MR:17.1,17.4 <APPROVED> "Pointer increment needed" */
    g_i2cTransfer_t.data++;
    g_i2cTransfer_t.length--;

    if(g_i2cTransfer_t.length == 0U)
    { /* Disable TX interrupt after desired data count transfered*/
    i2cREG1->IMR &= (uint32)(~(uint32)I2C_TX_INT);
    i2cNotification(i2cREG1, (uint32)I2C_TX_INT);
    }
    }

    Here, when the length is 0, that is in the last byte transfer, you disable the TX_INT and fire the notification. Thus, your claim that for last byte, Halcogen code doesn't generate interrupt is correct.

    However, I tried changing the code as follows.

    if (g_i2cTransfer_t.length > 0U)
    {
    i2cREG1->DXR = *g_i2cTransfer_t.data;
    /*SAFETYMCUSW 567 S MR:17.1,17.4 <APPROVED> "Pointer increment needed" */
    g_i2cTransfer_t.data++;
    g_i2cTransfer_t.length--;


    }else if(g_i2cTransfer_t.length == 0U)
    { /* Disable TX interrupt after desired data count transfered*/
    i2cREG1->IMR &= (uint32)(~(uint32)I2C_TX_INT);
    i2cNotification(i2cREG1, (uint32)I2C_TX_INT);
    }

    Now ideally, it should generate an additional interrupt. In the last interrupt, it should disable further interrupts and issue the notification. (For three bytes, there will be three interrupts)

    However, this is not happening. I've verified this behavior using logic analyzer and code composer studio debugger.

    If I place breakpoints and check the output in logic analyzer, I can properly get interrupts for first two bytes, but the third interrupt doesn't fire.

    For multi byte transfers, this is alright. However, for 1 byte transfers the notification never comes due to this behavior. That is where I started looking into this.

    It would be great if you can check this with me and shed some light on this matter.

    Thanks!
  • 0 in reply to Pradeepa Senanayake
    TI__Guru**** 199096 points
    Hello,

    The 1st byte is transferred without generating the TXRDY interrupt. The TX interrupt is enabled just after the data is copied to i2CDXR and moved to I2CXSR. TXRDY is generated when the transmitted data has been copied from the data transmit register (I2CDXR) into the transmit-shift register (I2CXSR).