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.

The problem with handling McAsp interrupt in the DSP/BIOS.

Hello! I am try use McAsp bus in next configuration:Frame SYNC and CLK(960 KHz) internal; TDMA mode( 5 slots; slot size 8 bit; first slot inactive ); SYSCLK2 = 150MHz . And also for process Transmit Data Ready Interrupt I am use DSP/BIOS Interrupt Dispatcher. In this case I am see only 2-3 interrupt, after all freeze. After I am try use more slot size( 32 bit ) in this case all work fine. How I am understand this problem caused by DSP/BIOS interrupt Dispatcher latency, because my HWI function is very simple and use only one operation data copy. Also I am place all DSP/BIOS and my HWI function in IRAM. Can you tell me what latency( nymber of DSP cycles) have DSP/BIOS Interrupt Dispatcher( now I am have 1200 cycles DSP service time( time then I am can write data in XBUF)), but it is seems not enought?

  • Hi,

    Could you please mention the following details?

    1. DSP/BIOS version.

    2. BIOS PSP version from which you have taken the McASP driver.

    3. The EVM(board) being used.

    Thanks and Regards,

    Sandeep K

  • I am not use evaluation board, this is our device. It based on C6745 chip. Also I am use CCS 3.3 DSP/BIOS 5.33.05 and I am not use PSP. From DSP/BIOS I am use only some SWI and Interrupt manager. It seems caused by no enought time for process HWI by DSP/BIOS, because in mode with EDMA and process 240 burst * 5 timeslot in each*8 bit all work fine( interrupts from EDMA come only then we transmit all this block data; every 10 ms). Can you tell me what average time need DSP/BIOS for process HWI( what minimum interval between interrupts)? From my some experiment with McAsp frequency this time about 10 us.

  • Hi Ilgiz --

    Please see timing benchmarks for BIOS 5.x.   The 674x timings should be same as the 64x and 64x+ timings.

    http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/bios/dspbios/5_41_10_36/exports/docs/packages/ti/bios/benchmarks/html/Results.html

    If you place the BIOS interrupt code in on-chip memory (IRAM means L2 RAM), then (from table below) I'd expect the times to be around 144+144 of overhead (prolog+epilog) for the BIOS HWI dispatcher.   This works out to be about 1us on a 300MHz device.

    You should be able to put a breakpoint on the interrupt vector and look at the TSCL register in register window.  Then put another breakpoint at the beginning of your ISR and look at TSCL register.  And subtract the 2.  This will be time it takes BIOS to handle your interrupt.  And then put b/p at the end of your ISR and at the IRP (interrupt return address) and look at TSCL at both of these points to see the back end.   You should set IER to 0 at the interrupt vector to disable all other interrupts including yourself for this measurement.  You can find the interrupt vector base address by reading ISTP register in the register window.

    Be careful with your IER mask setting when you plug this interrupt with the dispatcher.   You should set it to ALL (or 0xffff I think) to disable all other interrupts when your ISR is running..  This will keep the timer interrupt and any other lower priority interrupts from preempting with your high priority interrupt.   You should also map your high priority interrupt to interrupt #4 to make it the highest priority interrupt.   When more than one interrupt is pending while interrupts are disabled,  the highest (lowest number) will be taken first.

    -Karl-

    Version: C64XX On-Chip

    benchmarks @(#)DSP/BIOS_Benchmarks 5,2,4,5 10-02-2007 (bench-h11)

    Timing Benchmarks

    Benchmark Cycles
    Interrupt latency 184
    HWI_enable 24
    HWI_disable 24
    HWI_dispatch: Interrupt prolog for calling C function 144
    HWI_dispatch: Interrupt epilog following C function call 144
    SEM_ipost: Hardware interrupt to blocked task 1024