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

TMS570LS3137 - GIO Interrupt latency

Yanzhong Li
Intellectual 470 points
Other Parts Discussed in Thread: TMS570LS3137

Zhaohong or Other experts,

Here comes my question about TMS570LS3137 GIOA interruption timing analysis.

My system uses SPI to read data from the external ADC. An external trigger signal comes to GIOA-2 pin, and triggers an interruption. In ISR of the GIOA interruption, MCU reads the data.  Now I just wrote a piece of codes to test the data sampling speed.

I toggled a GPIO pin as a flag at the beginning of ISR to observe the GIOA interruption response time - from the external signal trigger edge to the flage change edge.

My system clock is about 180MHz (179.712MHz), so its period is 5.56ns. However, the measured interruption response delay (for external trigger to entering ISR) is 808ns.  In other words, it takes about 145 system clock cycles.  It is a big surprise to me and this is absolutely not acceptable.

It seems something wrong. Thus want to get your comments for optimization.

(1) I set the GIOA interruption as IRQ, and use Interruption vector #10 in VIM. Is the 145 system clock cycles is reasonable? If not, what's the reasonable number?

(2) I am using IAR embedded workbench as IDE and coding in C. How much the complier can affect the efficiency, thus affect the delay? 

How's if I use assembly language?

(3) Instead of IRQ, will FIQ can help to shorten the interruption response delay?

(4) any other factors can help to reduce the delay? for example, special settings on GIOA control registers etc. 

 

Any suggestion from the Forum is appreciated!

Thanks,

Yanzhong

 

 

 

  • 0
    TI__Mastermind 49120 points

    Yanzhong,

    I have split your post from the earlier conversation as this is a unrelated topic. I have also renamed the post to match the topic of discussion.

    I am looking into this and will get back to you with more information.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Intellectual 470 points

    Sunil,

    I'd like to explain a little bit more about the 145 system clock cycles.

    My system actually used SPI1 (master mode) and SPI3 (Slave mode) to read Dual channel data simultaneously.

    My ISR basically includes below steps to read and store the data.   I checked the disassembly language in the debugger. It does list many assembly instructions for each C instrunction.

    I will look into it.

    Please provide the advice for reducing the overall GPIO interruption latency and the data store processing time.

    The ISR steps (in C):

    (1) Disable interruption

    (2) Change a flag signal output status - A toggling signal for testing

    (4) Update the 1 million pulse counter by ++

    (5) Check if data array WRITE index reach the max, if yes, rollover the index

    (6) Dummy write to SPI port to

    • generate ADC_/CS to start a conversion at falling edge and stay low for data be read out
    • generate the SPI clocks for ADC clock data out

    (7) Check and Wait for SPI data ready

    (8) Read data (2 channel) and store them into data array

    (9) Update the data array WRITE index by ++

    (10) Check if total counter number reach 1 million - if yes, set the flag and reset the counter to zero

     (11) Change a flag signal output status - A toggling signal for testing

    (12) Enable the interruption

    (13) Exit

     

    Thanks,

    Yanzhong

  • 0 in reply to Yanzhong Li
    TI__Mastermind 49120 points

    Hello Yanzhong,

    Sorry for the really long delay in getting back to this post.

    I measured the interrupt latency for servicing an IRQ to be 47 CPU clock cycles. This measurement is done using the Performance Monitoring Unit (PMU) which is embedded inside the Cortex-R4F CPU itself.

    A measurement done using a general-purpose I/O pin as the marker has the peripheral access latency included as part of the measurement. The peripheral accesses (writes) take about 22 CPU clock cycles.

    Another comment on your ISR sequence: you do not need to explicitly disable/enable interrupts in the ISR. Once the CPU switches its operating mode to the IRQ mode in order to execute an ISR, it automatically disables any further IRQs. Any more IRQs will be held pending inside the interrupt manager and will be sent to the CPU once it switches back to the mode it was in before it entered IRQ.

    Regards, Sunil