- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
I encountered some problems with EDMA completion interrupt, which was reported in my posting below:
http://e2e.ti.com/support/embedded/f/355/p/137259/497771.aspx#497771
Instead of continuing that thread for my new findings, I create this new thread for my findings/problems/questions as below. In all my examples, I uses sysbios CpIntc for interrupt and shadow region for my Edma channels. Futhermore, for the log below, edmaId (0, 1, or 2) is Edma controller index, and m_intcId (0, or 1) is the interrupt controller index. I also uses "//" at the end of some log lines to provide my comments. Now the problems/questions:
1. If I uses different host interrupts which maps to the same primary event, then I will get E_unpluggedSysInt error. The following shows the trace:
[C66xx_0] edmaId(1), m_intcId(0): m_sysInt(8) => m_hostInt(32)
[C66xx_1] edmaId(1), m_intcId(0): m_sysInt(9) => m_hostInt(43)
[C66xx_0] dstMsg(0082ca58), m_dspSeqNum(0), m_sysInt(8) // Here an Edma transfer request is issued.
[C66xx_0] CTraceQ::TraceEdmaCompleted() – 1 core0 // Edma transfer is completed.
[C66xx_1] ti.sysbios.family.c66.tci66xx.CpIntc: line 311: E_unpluggedSysInt: System Interrupt# 0 is unplugged
ti.sysbios.gates.GateMutex: line 97: assertion failure: A_badContext: bad calling context. See GateMutex API doc for details.
[C66xx_1] xdc.runtime.Error.raise: terminating execution
I do not have the this problem if host interrupts are mapped to different primary events. Can anyone tell me why Edma and sysbios CpIntc behaves like this? Is this an Edma or Bios problem? If not, does this means that one should never use host interrupts mapped to the same primary event?
2. For cores 0 to 3, if I have each core setup to use Edma completion interrupt and setup the CpIntc accordingly, an EDMA completion from one core will trigger interrupt for all other cores. Here the other cores issued no Edma request. The same applies to cores 4 to 7 using the 2nd CpIntc. The following traces show this problem:
[C66xx_7] edmaId(1), m_intcId(1): m_sysInt(15) => m_hostInt(72)
[C66xx_1] edmaId(0), m_intcId(0): m_sysInt(39) => m_hostInt(44)
[C66xx_0] edmaId(0), m_intcId(0): m_sysInt(38) => m_hostInt(32)
[C66xx_2] edmaId(0), m_intcId(0): m_sysInt(40) => m_hostInt(56)
[C66xx_3] edmaId(0), m_intcId(0): m_sysInt(41) => m_hostInt(68)
[C66xx_4] edmaId(1), m_intcId(1): m_sysInt(12) => m_hostInt(36)
[C66xx_5] edmaId(1), m_intcId(1): m_sysInt(13) => m_hostInt(48)
[C66xx_6] edmaId(1), m_intcId(1): m_sysInt(14) => m_hostInt(60)
[C66xx_0] dstMsg(0082c918), m_dspSeqNum(0), m_sysInt(38) // issue Edma request
[C66xx_2] CTraceQ::TraceEdmaCompleted() - 1 core2
[C66xx_3] CTraceQ::TraceEdmaCompleted() - 1 core3
[C66xx_0] CTraceQ::TraceEdmaCompleted() - 1 core0
[C66xx_1] CTraceQ::TraceEdmaCompleted() - 1 core1
[C66xx_4] dstMsg(0082cd18), m_dspSeqNum(0), m_sysInt(12) // issue Edma request
[C66xx_5] CTraceQ::TraceEdmaCompleted() - 1 core5
[C66xx_6] CTraceQ::TraceEdmaCompleted() - 1 core6
[C66xx_7] CTraceQ::TraceEdmaCompleted() - 1 core7
[C66xx_4] CTraceQ::TraceEdmaCompleted() - 1 core4
I thought that each completion should only triggers its own interrupt. Each core uses its own Edma channel, own system int, own host int and own hwi. The mapping between host int and hwi is done in cfg script as below:
CpIntc.mapHostIntToHwiMeta(32 + 11*0 + 0, 4 + 0);
CpIntc.mapHostIntToHwiMeta(32 + 11*1 + 1, 4 + 8);
CpIntc.mapHostIntToHwiMeta(32 + 11*2 + 2, 4 + 2);
CpIntc.mapHostIntToHwiMeta(32 + 11*3 + 3, 4 + 3);
CpIntc.mapHostIntToHwiMeta(32 + 11*0 + 4, 4 + 4);
CpIntc.mapHostIntToHwiMeta(32 + 11*1 + 5, 4 + 5);
CpIntc.mapHostIntToHwiMeta(32 + 11*2 + 6, 4 + 6);
CpIntc.mapHostIntToHwiMeta(32 + 11*3 + 7, 4 + 7);
Can anyone tell me why one Edma completion system interrup trigers other interrupts?
3. If core4 using the third Edma controller and the following settings, the Edma completion causes E_stackOverflow erro even if only this core is doing usefule work, while the other cores are just sleeping. I do not have this problem if this core uses the 2nd Edma controller. Can anyone tell me why or can reproduce this problem?
Channel number: 5
Parameter number: 5
Que number: 0
Region number: 4
Hwi: 6
[C66xx_4] edmaId(2), m_intcId(1): m_sysInt(28) => m_hostInt(36)
[C66xx_4] ti.sysbios.knl.Task: line 334: E_stackOverflow: Task 0x1 stack overflow.
[C66xx_4] xdc.runtime.Error.raise: terminating execution
Dongning
Dongning,
In your source code, it looks like you enable every channel in every shadow region.
if (instNum == 0)
{
/* YES. DRAE enable(Bits 0-15) for the shadow region; since there are 16 channels. */
regionAccess.drae = 0xFFFF;
regionAccess.draeh = 0x0;
}
else
{
/* YES. DRAE enable(Bits 0-63) for the shadow region; since there are 64 channels. */
regionAccess.drae = 0xFFFFFFFF;
regionAccess.draeh = 0xFFFFFFFF;
}
It will cause problem that one transfer completion will generate the interrupts to all the shadow regions. You can try to not overlap the channel allocation and transfer completion code among the shadow regions.
Please refer to the A.2 Miscellaneous Programming in the EDMA user guide.
Hope it can solve your interrupt issue.
Sincerely,
Steven
