• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 81 subscribers
  • Views 345 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.

TMS320F280039C: Are both I2CA and I2CA_ FIFO ISR required in the PMBus over I2C examples?

Wayne Huang
Genius 15590 points
Part Number: TMS320F280039C

Dear Champs,

I am asking this for our customer.

The user is thinking to refer to our PMBus over I2C examples for their project.

It appears both I2CA ISR and I2CA_ FIFO ISR are used in the master and in the slave examples.

Why are both ISR needed here?

If the user wants to include our PMBus over I2C library, do they also need to use both ISRs?

Because the user uses nesting ISR, when they use these two ISR, which one should be prior or they should be in same priority?

Wayne Huang

  • 0
    TI__Guru 55700 points

    Wayne,

    Wayne Huang said:
    Why are both ISR needed here?

    Yes. Both I2C ISR routine are needed. State machine depends upon both the ISR routines.

    I2C ISR handler        - Gets triggered under STOP condition and Transmit ready

    I2CFIF0 ISR handler - Gets triggered by RX FIFO interrupt

    Wayne Huang said:
    Because the user uses nesting ISR, when they use these two ISR, which one should be prior or they should be in same priority?

    Both I2C interrupt and I2C FIFO interrupt in CPU (INT8) I2C interrupt line. But, I2C interrupt has higher priority over I2CFIFO interrupt

    Regards,

    Manoj

  • 0 in reply to Manoj Santha Mohan
    TI__Genius 15590 points

    Dear Manoj,

    About the priority, let me make it clearer.

    I understand I2CA is INT8.1 and I2CA_FIFO is INT8.2 by hardware priority without nesting interrupt by default.

    Here, the user uses software nesting ISR because there are many ISR in his project and he wants ISR of higher priority can interrupt these ISR of lower priority.

    In our example, because there are only two ISRs and there is no software nesting ISR used. We can assume they could be just set in the same priority and let hardware priority - INT8.1 and INT8.2 run by default. In this case, if INT8.2 ISR is serviced first, INT8.1 ISR sill needs to wait until INT8.2 ISR completes.

    We wonder if this (INT 8.1/8.2 of the same software priority) is still what we suggest even if the user can change their priorities by software.

    Or do we suggest using software nesting to let INT8.1 to interrupt INT8.2 when INT 8.2 is being serviced first for better performance?

    Wayne Huang

  • +1 in reply to Wayne Huang
    TI__Guru 55700 points

    Wayne,

    I2C interrupt (8.1) gets triggered only on STOP condition / transmit data ready interrupt. So, user software nesting to let INT8.1 instead of INT8.2 should be okay as RX FIO interrput is used to read the FIFO results from the RX buffer.

    Regards,

    Manoj

  • 0 in reply to Manoj Santha Mohan
    TI__Genius 15590 points

    Dear Manoj,

    I have integrated this PMBus over I2C examples into another codes with many nesting ISRs running simultaneously.

    To my surprise, I2CFIF0 ISR handler (INT8.2) had to be prior to I2C ISR handler (INT8.1) in software priority to keep it run well continuously.

    It would get stuck if I set I2C ISR handler (INT8.1) equal to or prior to I2CFIF0 ISR handler (INT8.2).

    For your information.

    So far, I only tested these tests that could be run well based on this post.

    https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/1081943/tms320f280039c-failure-when-testing-pmbus-over-i2c-examples-continuously/4010116#4010116

    Wayne

  • 0 in reply to Wayne Huang
    TI__Guru 55700 points
    Wayne Huang said:

    To my surprise, I2CFIF0 ISR handler (INT8.2) had to be prior to I2C ISR handler (INT8.1) in software priority to keep it run well continuously.

    It would get stuck if I set I2C ISR handler (INT8.1) equal to or prior to I2CFIF0 ISR handler (INT8.2).

    Can you share your modified code which prioritize INT8.2 over INT8.1?