Forums » Software Development »
L138 - DSP Timer interrupt question ...
Added by Thomas Catalino over 11 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 over 11 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 about 11 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 about 11 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 about 11 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
