C6747 DSP misses EDMA3 TC Interrupt occasionally.

Shintaro,

When the EDMA interrupt is missed, do you get the next one or do you get no further EDMA interrupts?

Can you take the ECM out of the picture and tie those two interrupts directly to HWIs?

Regards,
RandyP

RandyP,

Thank you for your reply.

When the EDMA interrupt for SPI data transfer is missed, other EDMA interrupts occur exactly.

The PaRAM for SPI data transfer is linked to the copy of itself, and the copy is loaded to PaRAM 18 or 19 (which is reserved for SPI Rx or TX event) even though the TCINT was dropped. If the Host CPU send a command message through SPI again, then the TCINT happens this time.

To take the ECM off, I configured the interrupt setup in .cfg file as below.

----------------------------------------------------------------------------------------------

//setup for EDMA ISR

var instHwiParams0 = new Hwi.Params();
instHwiParams0.instance.name = "edma3ccInt";
instHwiParams0.eventId = 8;
Program.global.edma3ccInt = Hwi.create(6, "&edma3ccIsr", instHwiParams0);

//setup for GPIO ISR

var instHwiParams1 = new Hwi.Params();
instHwiParams1.instance.name = "gpio_b0Int";
instHwiParams1.eventId = 65;
Program.global.gpio_b0Int = Hwi.create(7, "&gpio_b0Isr", instHwiParams1);

----------------------------------------------------------------------------------------------

I tested them, but the situation didn't change.

If you have more ideas or some information, please let me know.

Regards,

Shintaro

Shintaro-san,

Removing the ECM has helped to eliminate that logic and software from the possible problem. Once the problem is resolved, you can safely go back to using the ECM. Thank you for trying that test.

Your explanation of the linking for the SPI PaRAM is clear. The facts that the data transfers continue and that the interrupts will resume after missing one, these lead me to suspect that the interrupt is being skipped due to missing the real-time requirement in software and not due to hardware problems with clearing the interrupt bits. What I mean is that some hardware issues could occur where interrupt flag bits or status bits could miss being cleared, but that would usually lead to a complete failure to receive more interrupts. In your case, the interrupts continue so the hardware system is healthy as implemented in your application.

The next thing to determine is where the interrupt is being missed. This could be because the IPR bit is set in the EDMA3 hardware register and does not get cleared before the next SPI event occurs. Or it could be because the second EDMA3CCINT interrupt signal occurs before the ISR has had a chance to complete servicing a prior interrupt or a higher priority interrupt.

One register to test is the INTXSTAT register described in the Megamodule Reference Guide. This will let you know if a second interrupt occurred while waiting for the first interrupt to be serviced. If the EDMA3CC IPR bit causes the DSP IFR bit to be set, this will generate an interrupt request inside the DSP. If the DSP is busy doing other things and another EDMA3CC IPR bit causes the DSP IFR bit to be set before the first one has been serviced, then the DROP bit in INTXSTAT will be set and the event that caused DROP will be latched in the register. To check this, put some code in your ISRs to read INTXSTAT and test the DROP bit. This is easy to test, but this condition is protected very well by the design of the EDMA3CC interrupt signalling. I do not expect this to be the problem, but it is easy to test and eliminate.

The more likely cause, in my opinion, is that the SPI data interrupt occurs too often for the ISR routines to keep up with it. If you execute a lot of processing in your GPIO ISR or in any other ISRs, then it is possible to hold off a lower priority interrupt like this one for the SPI. If that interrupt is held off too long, then an interrupt will be missed even though the data was successfully captured and saved.

Please help us to understand the timing of your different events and the amount of processing work done in the ISRs. How much time occurs between SPI interrupts from the EDMA? How much processing is done in that SPI ISR or in other EDMA-related ISRs? How much processing is done in the GPIO ISR?

Regards,
RandyP

RandyP,

Thank you for your quick reply.

Actually I've once checked the INTXSTAT register, but then DROP indicated no interrupt was dropped. I assigned an interrupt handling function to event #96 (Interrupt Missed Event of Interrupt Controller), but it has never be called. But, thanks to your explanation, the mechanism of interrupts is getting clearer for me, so I'm going to check it again.

Under a heavy load, SPI Rx Interrupts occurs once every 330 micro sec, and Tx Interrupts occur by the same frequency.

In EDMA ISR, I only clear the IPR bit flag and post a semaphore. In GPIO ISR,  I only set a flag bit, and then leave the ISR function. Both of them don't take so long time.

I'm checking the IPR register in a manner as below.

----------------------------------------------------------

void edma3Isr()

{

   while(edmaCcRegs->IPR) {

      if(edmaCcRegs->IPR & (1 << EDMA_TCC_SPIRX)) {

         edma_IntClear(EDMA_TCC_SPIRX);

         Semaphore_post(spirx_fin_sem);

      }

      (similarly)

----------------------------------------------------------

This is jst a quick note and I'll get back to this later.

Thank you so much!

Regards,

Shintaro

Shintaro-san,

In the thread EDMA3 EMR, there is a project posted for the C6455 DSP that includes edmaIntDispatcher.c and .h. In the other project .c files are examples how the functions in these files are called and used. They provide a well-tested way to handle multiple events from the EDMA3 module that can cause interrupts and also provide for repeated IPR bits being set that could be missed.

The methods used in EdmaIntDispatcher prevent the loss of an interrupt due to IPR bits being set close in time to each other. This can happen anytime you have more than one IPR bit that will be used for a DSP interrupt, if those EDMA3 transfers are asynchronous to each other. This is one possibility for missing an IPR bit.

330us is a long time for the DSP, so this is normally not going to result in a missed interrupt. But there could be situations in your application that would result in a long latency that could miss an event. Some of these are:

• Other IPR bits are set first and their ISRs take up part of the 330us available between events.
• Other interrupts, like the GPIO interrupt, could also occur first and might prevent the EDMA interrupt from preempting them. This could be helped by changing the interrupt mask value for the other interrupts to allow higher priority interrupts to preempt the lower priority interrupts, or just allow the EDMA interrupt to preempt them.
• Higher priority interrupts could be executing and causing a longer latency before the EDMA interrupt is reached. This is unlikely since you are using interrupt 6 for the EDMA, but if anything is still using the ECM on 4 or 5, those could starve out the EDMA interrupt.
• Code executing in an ISR or in normal code could prevent interrupts for a short time during some tight processing loops. You can use the -mi compiler switch to control the maximum time that interrupts can be disabled.
• Some library functions may turn off interrupts for a short time while they execute their operations.

If you will offer some descriptions of the timing of the SPI commands and your observations of which SPI events tend to get missed, it may help us to understand the sequence that needs to be fixed. Also, it could be helpful to identify any other EDMA IPR bits that could be set and any other system interrupts that could occur.

Regards,
RandyP

RandyP,

I checked INTXSTAT register again and now I have a question about it.

When I see DROP field in INTXSTAT register, it is always set to 1. SYSINT field is set to 4 (Timer64P0_TINT12 event), and CPUINT is also set to 4 (CPUINT #4). Event #4 is masked in Interrupt Controller, and I don't use CPUINT #4 explicitly. Where does this come from?

I don't know about the timer at all, so if you don't mind, please tell me about it in brief.

I suppose that the timer is used by SYSBIOS.

Anyway, I want to see if EDMA3CCINT was dropped by checking INTXSTAT. How can I do it?

Regards,

Shintaro

Shintaro-san,

When an interrupt is missed, the interrupt drop detection logic will latch the appropriate information into the INTXSTAT register. I believe that this information will remain latched even if another interrupt is missed, so that second missing interrupt will not be latched into INTXSTAT. You may clear the INTXSTAT register by writing 1 to INTXCLR, then another missed interrupt will be latched into INTXSTAT. If you have some interrupts that you do not care about, you may write a 1 to the corresponding bits in the INTDMASK register to prevent them from being latched into INTXSTAT. It may be good practice to clear INTXSTAT before enabling interrupts to be sure the correct values will be latched.

The documentation is not clear to me what the relationships are between the System Event number and the CPU interrupt number, but these may be implied from your interrupt configuration. The interrupt configuration in your SYS/BIOS configuration should show what, if anything, is configured for this timer interrupt and the CPU interrupt #4. It could be a problem, or it could be the correct result, or it could be irrelevant information that needs to be cleared from the register.

The timer used by SYS/BIOS is usually a low priority interrupt, at INT15 or INT14. The timer is used to generate an interrupt from which SYS/BIOS will run all of its scheduling operations and will also schedule periodic functions, if you define those.

To check EDMA3CCINT in INTXSTAT, be sure to clear the INTXSTAT register and then put register read & test code in your ISR. This will indicate too late that an interrupt was missed, but it may be the first opportunity to catch it.  You might also read the IFR register to see if another interrupt is sometimes pending for the EDMA ISR to complete; this could be a good indication that sometimes that other interrupt might be holding off the EDMA ISR.

Regards,
RandyP