Forums

High Interrupt Latency with TI Chip Support Library

Started by vishnupsn August 23, 2008
Hi experts,

I am working with TI DM6446 ( DaVinci EVM )which has a 64x+ core and ARM9
Core. I am  developing an interrupt driven application in the 64x+ core (
Code Composer Studio project). In this context I see a strange behaviour
when the  CCS project uses  TI Chip Support Library (CSL) for configuring
Interrupt handlers. The interrupt latency is very huge, of the order of 3-4
microseconds.  However, when DSP BIOS is used for Interrupt handler
configuration, the latency is only 1-2 microseconds. Has any one seen such
kind of latency?  Interestingly, if I setup the Interrupt handler ( without
CSL or DSP BIOS)  by properly setting the relevant  registers and vector
table, I get still lower latency. FYI, the 64+ core is operating at 594Mhz
and is expected to give only a latency of less than 15 clock cycles. 

I am calculating the latency by measuring the width of a pulse on a GPIO
pin of the DSP,  which is set high  when interrupt event occurs, and reset
the begining of the  ISR. This ensures that whatever error   occurs  in
measurement ( even if GPIO pin latency  is encountered) would be applicable
to all 3 modes of Interrupt vector setting mentioned above. 

Now my question is , has any one encountered such high Interrupt latency
while using TI CSL? If not can some one give a possible explanation for the
behaviour ?

If this is not the right forum to ask this question can some one direct me
to the right place.


Thanks in advance,

Cheers

Vishnu Prasad S.N



vishnupsn wrote:
> Hi experts, > > I am working with TI DM6446 ( DaVinci EVM )which has a 64x+ core and ARM9 > Core. I am developing an interrupt driven application in the 64x+ core ( > Code Composer Studio project). In this context I see a strange behaviour > when the CCS project uses TI Chip Support Library (CSL) for configuring > Interrupt handlers. The interrupt latency is very huge, of the order of 3-4 > microseconds. However, when DSP BIOS is used for Interrupt handler > configuration, the latency is only 1-2 microseconds. Has any one seen such > kind of latency? Interestingly, if I setup the Interrupt handler ( without > CSL or DSP BIOS) by properly setting the relevant registers and vector > table, I get still lower latency. FYI, the 64+ core is operating at 594Mhz > and is expected to give only a latency of less than 15 clock cycles. > > I am calculating the latency by measuring the width of a pulse on a GPIO > pin of the DSP, which is set high when interrupt event occurs, and reset > the begining of the ISR. This ensures that whatever error occurs in > measurement ( even if GPIO pin latency is encountered) would be applicable > to all 3 modes of Interrupt vector setting mentioned above. > > Now my question is , has any one encountered such high Interrupt latency > while using TI CSL? If not can some one give a possible explanation for the > behaviour ? > > If this is not the right forum to ask this question can some one direct me > to the right place. > > > Thanks in advance, > > Cheers > > Vishnu Prasad S.N >
When looking at interrupt latency I think there are 2 main components you should consider: 1) Delay in taking the interrupt due to interrupts being disabled. I don't know what else is happening in your system but certain library routines, etc. will disable interrupts while they are processing. This can cause interrupt latency. Also, the 64x+ core is uninterruptible during the delay slots of a branch, so tight loops can cause the device to be uninterruptible. This is less of a problem than it used to be due to the SPLOOP hardware that was introduced in the 64x+ core. 2) Delay in the interrupt handler. In the case of DSP/BIOS you have the choice of using the HWI_dispatcher or plugging the interrupt directly into the table. Using the HWI_dispatcher is recommended but it will add a small amount more latency. You're talking about 1200 cycles of interrupt latency using DSP/BIOS and 2400 cycles of latency using CSL. Try to break that down further to figure out what the CPU is doing during all those cycles. Brad