• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 82 subscribers
  • Views 392 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.

TMS320F280039C: ePWM Interrupt Latency on F28003x (~200ns)

Bhandavi Eduresapu
Prodigy 50 points

Part Number: TMS320F280039C
Other Parts Discussed in Thread: C2000WARE

Hi,

I am using the TMS320F280039C device with SYSCLK = 120 MHz.

I configured EPWM1 interrupt to trigger at TBCTR = 0.
Inside the ISR, I set a GPIO pin High and then immediately Low to measure timing.

Only this single interrupt is enabled in the system.

When I measure on the oscilloscope, I observe that the GPIO goes HIGH approximately 200 ns after the TBCTR = 0 event.

I am running the code from Flash.

Is this delay expected due to interrupt latency, or is there another reason?

Thank you.

  • 0
    TI__Expert 6010 points

    Bhandavi,

    Yes, that is expected behavior and your assumption is correct. Additional to interrupt latency, there is software writing delay along with few 1~2SYSCLKs associated with GPIO turn on and off if that GPIO buffer is synced with SYSCLK.

    Regards,

    Sumit

  • 0
    Prodigy 50 points

    Thank you for the explanation.

    I understand that interrupt latency and GPIO synchronization contribute to the delay. However, I am still a bit confused about the numbers.

    From the Testing, the interrupt latency is about 75 ns.
    At 120 MHz, one SYSCLK cycle is ~8.33 ns, so even accounting for 1–2 SYSCLK cycles for GPIO synchronization, that would add only about 8–16 ns.

    So roughly, the total delay should be around 90 ns, but I am observing about 200 ns on the oscilloscope.

    Could you please explain what accounts for the additional delay?

  • 0 in reply to Bhandavi Eduresapu
    TI__Expert 6010 points

    Bhandavi,

    What code are you using for GPIO ON/OFF? Is it C2000 API function or bit field code?

    Is there any additional code in ISR apart from GPIO for this?

    Regards,

    Sumit

  • 0 in reply to Sumit Patil1
    TI__Expert 6010 points

    Bhandavi,

    I just observed that that you are running the code from Flash, in this case 200 ns latency which is approximately 24 clock cycles at 120 MHz is consistent with the expected interrupt response time when executing from Flash. Following is breakdown of the timing of the whole process:

    1. Interrupt Recognition & Pipeline Flush: 8-12 cycles
    2. Context Saving: 14-16 cycles (saving CPU registers to stack)
    3. Flash Access Overhead: 5-10 cycles (Flash wait states)
    4. ISR Entry & GPIO Operations: 3-5 cycle

    Regards,

    Sumit

  • 0 in reply to Sumit Patil1
    Prodigy 50 points

    Hi Sumit,

    Thank you for your detailed explanation.

    I would like to know if there is any recommended method to further reduce this delay

    Are there compiler optimization settings that help in reducing ISR latency?

    Please let me know if there are any additional best practices to achieve lower latency.

    Regards,
    Bhandavi

  • 0 in reply to Bhandavi Eduresapu
    TI__Expert 6010 points

    Bhandavi,

    Few notes, generally any digital control software code, it is recommended that ePWM event (CMPA/B, ZERO, PRD) starts the ADC start of conversion (SOC) and once ADC conversion is finished, ADC end-of-conversion EOC trigger ISR, this way are are sure that samples are ready to process in ISR. We have rarely seen interrupt trigger by ePWM in closed loop digital control

    To answer your question, although ISR latency is inevitable, there are multiple ways to reduce this delay as follows:

    1. Make code executed from RAM instead of flash: Flash has wait states, making code execution slower. Copy critical ISR code and related functions from Flash to RAM (.TI.ramfunc) during initialization. You can refer some of the reference design code examples in C2000Ware DPSDK for the syntax or implementation.

    2. You can make this interrupt "HPI" i e. high priority interrupt. This way all the float values and instruction gets copy in one cycle. By default any given interrupt in C2000 is LPI and you need to explicitly declare it HPI if needed. This will reduce latency further.

    3. For ISR profiling, if you are using GPIO, you can use bitfield code as you have done or use HWREG instruction to reduce API related delays.

    4. By default GPIO are synchronized with SYSCLK you can choose to make it asynchronous to reduce the delay.

    5. Once profiled these delays are fixed related to your code, you can trigger ISR early or ePWM delayed that will help you offset these delays.

    6. Although not available on all the devices, wherever available you can use the CLA instead of the main CPU for time-critical, math-heavy control tasks (e.g., PI controllers). The CLA can be triggered directly by ePWM, offering much faster response times than the CPU.

    It really depends on your application what solution applies from list above.

    Regards,

    Sumit

  • 0 in reply to Sumit Patil1
    Prodigy 50 points

    Okay i will try, Thank you.

  • 0 in reply to Bhandavi Eduresapu
    TI__Expert 6010 points

    Okay, feel free to reach out on e2e if any issue.

    Regards,

    Sumit