• State Resolved
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 310 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.

Interrupts ignores or delayed on custom C6713 target

Richard Olsen
Prodigy 40 points

Hi

Taget: Custom C6713 target @ 300MHz

We are using CCS 3.1.0 with BIOS Cuda 4.90.02.10 & Code generation v 5.1.0

System "tick" comes from external fpga @ 10kHz triggering INT4 HWI interrupt. External INT6 is triggered by CAN controller.

INT6 is set to use dispatcher with Interrupt bit mask to 'Self '

other 10kHz on INT4 can interrupt INT6 since interrupt bitmask is set to 'all' e.g. 0xffff.

Data transfer to FPGA is handled by 2 QDMA transfer from read/write locations.

When performing stress on the system via CAN that accesses slower SRAM with logs are interrupts sometimes delayed by 10-100+ us violating real-time requirements & triggering WD --> reboot.

Question: what can "keep" our INT4  from beeing serviced and effectively stalling the system.

I posted earlyer a related PRD question where it was asked if PRD's had to complete within 1ms e.g one tick. This was confirmed by the forum e3e TI response.

 

Is there a checklist to run over ensuring that we dont violate any DSP/BIOS rules & perhaps - does there exist a DSP/BIOS 4.90 "issue list" that we can chek up against.

 

I can recall that in early CCS days, that On CDB global setings property either all or none of the tick boxes for "Enable Real Time Analysis & Enable All TRC Trace Event Classes had to be checked - otherwise could unexpected behavior occour.

PIP releated question:

Is it allowed to have multible writers to one specific pipe with only ONE reader e.g "N to 1" configuration - if NO please state why & alternative.

 

Regards

Richard Olsen

 

 

  • 0
    TI__Mastermind 20805 points

    Richard Olsen said:

    Question: what can "keep" our INT4  from beeing serviced and effectively stalling the system.

    DSP/BIOS disables interrupts internally to protect some critical regions of code.   This disable is only for ~100 instructions max so this doesn't explain your 10-100us.   Your use of INT4 is best since this is the highest priority interrupt and will run before the others if more than one is pending when GIE is reenabled.   

    A few things to look for:

    [a]  Do you know if you have any code that disables interrupts?  

    [b] The other thing to look out for is the use of -mi compiler option to minimize the length time interrupts are disabled in loops.   If you have a long signal processing loop, the compiler might be compiling this loop to leverage software pipelining.  Such code must run with interrupt disabled.   You can use -mi10 to limit the length of time the compiler will disable interrupts to 10 instructions.

    [c] If you are not using RTA, I would suggest trying to disable RTDX to see if that helps.   You need to add the following code to your .tcf file to disable RTDX:

    bios.HST.HOSTLINKTYPE = "NONE";
    bios.RTDX.ENABLERTDX = 0;

     

    Richard Olsen said:

    Is it allowed to have multible writers to one specific pipe with only ONE reader e.g "N to 1" configuration - if NO please state why & alternative.

    Unfortunately, PIP only supports single reader and writer.  This was done to keep PIP as optimal and small as possible.    You might want to use MBX instead.   If you update to 5.xx (5.41.11 is the latest), you might want to take a look at MSGQ.

    http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/index.html

    Regards,
    -Karl-