Project

General

Profile

L138 - DSP Timer interrupt question ...

Added by Thomas Catalino about 8 years ago

(posted on behalf of a customer)

We are running on the board on the C674x side and have some success with our periodic timer interrupt. However, it seems we are not setting up the interrupt controller properly since we sometimes get periodic interrupts and sometimes we do not. It feels like it depends on the previous execution of code on the C674x after power-up. We are basically trying to get Tim12 to generate a periodic interrupt and Tim34 to be a separate, free running counter. We also are setup to field the Tim12 interrupt on the cpu interrupt 4. Below are the values we are putting in the timer registers, but we have no clue what to put in the interrupt controller registers 0x0180000 through 0x01800188. If you have any clues or a good contact at TI, that would be great!

Thanks,
Bill

TIM12_ADDR      .set    0 x01f0c010          ; Timer12 Counter Register
TIM12_VAL       .set    0                    ; Timer12 Value
TIM34_ADDR      .set    0 x01f0c014          ; Timer34 Counter Register
TIM34_VAL       .set    0                    ; Timer34 Value
PRD12_ADDR      .set    0 x01f0c018          ; Timer12 Period Register
PRD12_VAL       .set    20000000             ; Timer12 Period Value - 10ms default
PRD34_ADDR      .set    0 x01f0c01c          ; Timer34 Period Register
PRD34_VAL       .set    0 xffffffff          ; Timer34 Period Value
TCR_ADDR        .set    0 x01f0c020          ; Timer Control Register
TCR_VAL         .set    0 x00800080          ; ENAMODE34 = 2h, ENAMODE12 = 2h, timer is enabled continuously
TGCR_ADDR       .set    0 x01f0c024          ; Timer Global Control Register
TGCR_VAL        .set    0 x00000007          ; TIMMODE = 1h, timer is in dual 32-bit timer unchained mode, TIM34RS/TIM12RS = 1, not in rest
REL12_ADDR      .set    0 x01f0c034          ; Timer12 Reload Register
REL12_VAL       .set    0                    ; Timer12 Reload Value
REL34_ADDR      .set    0 x01f0c038          ; Timer34 Reload Register
REL34_VAL       .set    0                    ; Timer34 Reload Value
INTCTLSTAT_ADDR .set    0 x01f0c044          ; Timer Interrupt Control and Status Register
INTCTLSTAT_VAL  .set    0 x00020003          ; Enable Timer12 interrupt
EMUMGT_ADDR     .set    0 x01f0c004          ; Emulation Management Register
EMUMGT_VAL      .set    1                    ; Emulation Management Value, don't use stop bit

Replies (4)

RE: L138 - DSP Timer interrupt question ... - Added by Michael Williamson about 8 years ago

Are you running DSPLINK to load/run program the C674x side?

DSPLINK uses interrupt levels 4 and 5 for the ARM/DSP IPC. You might try using a level above 5 for the interrupt, particularly if you are seeing sporadic interrupt behavior.

Also, do you heavy looping code? The DSP loop optimization can create large interrupt latency as well (which can cause missed interrupts on things like large memory copies by the CPU, etc).

-Mike

RE: L138 - DSP Timer interrupt question ... - Added by François Tremblay over 7 years ago

Mike,

Can you add more details regarding this statement: The DSP loop optimization can create large interrupt latency as well (which can cause missed interrupts on things like large memory copies by the CPU, etc).

For example, which problem you seen in the past?
How big can be interrupt latency in such condition?

Thanks,

-François

RE: L138 - DSP Timer interrupt question ... - Added by Michael Williamson over 7 years ago

Check the "Interrupt Handling - Delayed Branch Latency" section of the Day2_AM training presentation located in our MityDSP-67XX project files folder.

It's for the 6711, but it also applies to the 674X core in the OMAP-L138.

Basically you want to use the "-mi" flag, and if you read up on the C6000 Optimizing Compiler manual there is more detail from TI.

We have seen very very large interrupt latencies (milliseconds) when running large memcpy calls to EMIFA type devices with optimized code (in the case of the 6711, to a parallel NOR with very slow timing). Some of the optimized dsplib calls from TI (the FFTs, etc.) can fill those branch delays pretty well and may stall interrupt handling as well if you are not careful.

-Mike

RE: L138 - DSP Timer interrupt question ... - Added by François Tremblay over 7 years ago

Mike,

Thanks for information. Always very intressting. I am reading the Day2_AM training document.

Here our current system. We are using UPP to get data from FPGA. There is a block of data around each 17 ms.
Correct me if I am wrong but knowing that UPP support 2 DMA request at the same time (current one and pending one),
it means that we are in trouble if interrupt latency is greater than 34 ms. Right?

Do you have see such number in the past (in term of interrupt latency)?

Our for() loop used to copy data are usually not bigger than 4096 iteration.
However, we are using DSP_fft32x32/DSP_ifft32x32 functions a lot (where npoints is 4096).
It seems that functions calls need 1.1 ms to execute. However, we call them in a for() loop (256 times). Can we need to
take some extra care?

We are also using DSP_fir_cplx where that takes around 1.3 ms to execute. DSP_fir_cplx_hM4X4() seems al little bit better
in term of "interruptability". DO we need to switch?

What is your feeling about that?

-François

    (1-4/4)
    Add picture from clipboard (Maximum size: 600 MB)