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.

TMS320C6743: EDMA3 transfer completion interrupt randomly stops reaching core

Part Number: TMS320C6743

Hi TI gurus.

I have a McASP RX ping-pong transfer that runs forever copying RX data to 2 x buffers in L2RAM.

The transfer itself seems fine and never seems to stop working, however I am currently being frustrated by an issue with interrupts.

I find that after some number of transfers (several hundred to several thousand seemingly randomly). The transfer complete interrupt stops actually executing the mapped ISR.

After this occurs I pause code composer and find that the EDMACC0 IPR has both of my TCC bits set.

I next check for events in the INTC0 EVTFLAG register. Sometimes I see event 8 (SYS_INT_EDMA3_0_CC0_INT1) set, and sometimes not.

However I then find that the core IFR is set to 0x0 (I re-checked that it is still mapped to the event).

I am not using an operating system.

What could prevent EDMA IPR bits from generating an INTC event?

What could prevent INTC events from generating a mapped core interrupt?

Is there some sort of race condition possible when clearing down the interrupt?

Many thanks,

James

  • Hi again,

    I'd really appreciate any help or suggestions anyone may have on this.

    Many thanks,

    James

  • James

    Sorry looks like we missed this query - i will ask my colleague to look at this - but we would really prefer that you use the code examples provided as part of the SDK. Given the intermittent nature of the failure , perhaps few things that will help diagnose the issue 

    1) How are you are writing your ISR and event handlers. 

    2) Is this test just with McASP / EDMA and EDMA completion for McASP the only interrupt going to DSP interrupt controller or do you have other peripheral interrupts or other EDMA channels/IPR bits in used to report transfer completion? That may help explain the race condition. 

    3) I am not sure what to make of your observations on IFR and EVTFLAGs - could it be that you are just seeing inconsistent behavior because by the time you poll/read these registers it is already changed status?

    4) Have you tried to reduce mcasp clock rate etc , to see if some how the rate of interrupts is too high causing some race condition?

    Regards

    Mukul