• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 29 subscribers
  • Views 790 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.

RM48 interrupt latency (again)

Frank Bormann
Mastermind 7585 points
Other Parts Discussed in Thread: HALCOGEN

I was following this thread:  http://e2e.ti.com/support/microcontrollers/hercules/f/312/p/247260/865774.aspx#865774 . In this thrad there was a remaining discrepancy in the number of clock cycles between the event and the ISR; 47 clock cycles (Sunil Oak) against 145  (Yangzong).

So I made a simple test case, based on HalCogen 3.06 and CCS5.4, which is:

RM48 running at 200 MHz (5ns).   HET1:0 as 10kHz-PWM- Signal, duty cycle 1:1.  Used a wire to connect HET1:0 to GIOA0. GIOA0 is programmed as input with IRQ- interrupt at GIO-high enabled. In the interrupt service routine for GIOA:0 another pin (GIOA1) is toggled. Use an oscilloscope to monitor HET1:0 and GIOA1.

Here are the results in form of the time between the rising edge at HET1:0 (wired to GIOA0) and the toggling of GIOA1 :

1. the GIOA1 - toggle- instruction (gioToggleBit(gioPORTA,1)) placed in function gioNotification: 960 ns

2. the toggle - instruction directly placed at the beginning of ISR-function gioHighLevelInterrupt:  660 ns

So even when I place the toggle instruction as first place in the ISR, it takes 660ns/5ns = 132 clock cycles!

Can anybody explain this large delay? It is a really long delay compared to other microcontrollers. Sunil mentioned in the thread above a "peripheral  access delay of about 22 cycles". Where can I find this in the documentation? What means "about", is this access delay a fuzzy number or is it fixed? Under what circumstances do I have to take into accout this access delay? Even when I subtract 22 cycles for writing GIOA1 from my result, there are still 110 cycles (or 550 ns) left. 

It would be nice to get a clear description of the timeline, how the RM48 acts regarding to interrupt latency.

 Frank

 

 

 

 

 

 

  • 0
    TI__Mastermind 49120 points

    Frank,

    I will look into this later today and post the code project that I used to measure the interrupt latency.

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Mastermind 7585 points

    Sunil,

    any news on that?

    Frank

     

  • 0 in reply to Frank Bormann
    TI__Mastermind 49120 points

    Frank,

    Sorry for the delay. I have attached a CCS project that you can use to measure the interrupt latency for an IRQ generated by driving a GIO pin. The GIOA[0] pin is used in this case as output from the part, so no external drive is required. The test case loads into and runs out of RAM so you will need to use the Scripts CCS menu command to switch the default memory map in order to map RAM at 0x00000000.

    I have also attached a document showing the chronological order of events in this code. As you can see, the PMU measurement is the closest to the actual interrupt latency, even if this measurement is somewhat larger than the actual number to be measured.

    1351.GIO_int_latency.zip

    5355.GIO_int_latency.pdf

    Regards, Sunil

  • 0 in reply to Sunil Oak
    Mastermind 7585 points

    Sunil,

    thanks for sending the files. Your pdf shows an interrupt latency of 112 cycles for a GIO-interrupt, which corresponds to my own results, see above. However, I did not switch the RAM over FLASH, but got similar results...

     Anyway, the initial question was about the RM4 Interrupt latency, and the result looks like 112 cycle, which is 560 ns at 200 MHz. I could not find this fact somewhere in the docs, did I oversee this or is it indeed a misssing spec?

    Also, your measurements mention a "time taken to write to GIODOUT".  Where can I find this time in the doc`s?

    Regards Frank

     

     

  • 0 in reply to Frank Bormann
    TI__Mastermind 49120 points

    Frank,

    The delay between the CPU executing the store instruction to write to the GIODOUT register and the GIODOUT register being actually updated is not typical and is dependent on several aspects. For example, if the DMA is also accessing a peripheral at the time when the CPU transaction occurs. This is the reason why this is not a specified parameter. We are, however, considering documenting the typical access times for various target slaves assuming an idle interconnect condition. Note that this idle interconnect condition may not be truly feasible.

    The interrupt latency is also not a fixed number and is dependent on the condition of the CPU when the interrupt occurs. This could be highly variable and so is not specified.

    Regards, Sunil