EDMA3 Error Interrupts on OMAPL138

Hi Marc

Marc said:

hat means that the arm gets error interrupts for errors which occurred on channels which are only used on dsp side and vice versa. Is this correct?

Yes, that is correct.

The CC/TC error interrupts are envisioned to be generated due to conditions that are more critical/fatal for the system/device, so there is a single interrupt line that goes to both processors.

There are some short comings in the current design of the EDMA3 on how CC errors get generated due to encountering a NULL entry (which can happen for a serial peripheral like McASP/McBSP/I2C etc where once you have finished/expired a PaRAM set and had it configured to Link to NULL , you still get another TX event from the peripheral to the EDMA , that can generate a CC error interrupt) , apart from that most of the other conditions are considered significant enough where both cores could be made aware of the error interrupts.

If you want ignore the error interrupt from CC/TC to a particular core, you would essentially need to filter it out by disabling those interrupts in the DSP or ARM interrupt controller.

Hope that helps.

Regards

Mukul

Thanks for your fast answer. I was just thinking about some error handling mechanism on the two processors which both use the edma3. So in the error isrs of the arm  I should check which channel caused the error and only handle the error if it is a channel which is used on arm side. The same should be done in the error isrs of the dsp. Thus each processors only handles errors which occurr on its "own" channels. Do you have any arguments against that or perhaps another proposal for the error handling?

Thank you

Hello,

the motivation behind this approach is just to encapsulate the channel specific error handling. If the errors are handled local, the arm doesn't mind errors on dsp edma channels and vice versa, while the system is still kept running (missed events are cleared,...). The global edma errors from the tc should be handled by the arm which should do a reset of the edma or perhaps of the whole system. We just use TI BIOS and no other TI software components since we have our own software framework.

Thanks for the information

Just an additional question about edma errors. If an event is received on a channel which contains NULL params the bit in the secondary event register remains set and the bit in the missed event register is set. In order to be able to receive subsequent events on that channel the bit in secondary event register must be cleared. What happens if a second event is received on a channel with non NULL params before the preceding event being serviced? Does the bit in the secondary event register remain set or is it cleared and just the bit in the event missed register is set. Can the channel still receive and process events without user action? Or is it necessary to clear the bit in secondary event register or in event missed register?

Thank you

Marc said:

What happens if a second event is received on a channel with non NULL params before the preceding event being serviced? Does the bit in the secondary event register remain set or is it cleared and just the bit in the event missed register is set. Can the channel still receive and process events without user action?

Under normal conditions ( non NULL param) the SER bit will automatically get cleared (in hardware) once the event has been de-queued , and it  doesn't require user intervention/software to clear this bit.

So if you get a second event (for a non NULL param) while the previous event on the same channel is still in the queue,  only the EMR bit will get set (and indicate the user via the error interrupt that an event has been missed). Under this condition, the channel will continue to receive and process events without user action.Only EMR being set will not prevent subsequent events to be latched and processed.

Regards

Mukul

I looked at your previous post on error handling , looks ok to me (thanks for clarifying).

Hello Mukul,

thanks a lot for the information. 

Mukul Bhatnagar said:

So if you get a second event (for a non NULL param) while the previous event on the same channel is still in the queue,  only the EMR bit will get set (and indicate the user via the error interrupt that an event has been missed). Under this condition, the channel will continue to receive and process events without user action.Only EMR being set will not prevent subsequent events to be latched and processed.

Does your quote apply to external, manual triggered, chain triggered and qdma triggered events or are there differences? What happens if a chain triggered event is being processed while an external event occurrs?

Regards Marc

Marc

EMR bit is specific to an event "type" (manual vs chain vs qdma vs external). EMR bit will only get set if you see a subsequent event of the same type, as the previous event , while the previous event is in the queue/being processed etc.

So if on the same channel you get a external event followed by a chain triggered event, EMR will not be set.

Let me know if you have additional questions on this.

Regards

Mukul

Hello Mukul

I have some questions about EDMA3 programming, I work on OMAPL137 and I choose to program directly the registers (without CSL or LLD). My objective is to write a transfer process (SPI0 peripheral servicing ). I have managed to program two EDMA channels. One gets DMA request from SPI0 Receive, another gets DMA request from  SPI0 Transmit. I also program two EDMA channels to generate a transfer completion interrupt to DSP (the final transfer interrupt in normal completion mode). But the EDMA generates a channel controller error interrupt besides the transfer completion interrupt. The following is the EDMA channels configuration :

EDMA channel configuration for SPI0 Receive:

SPIREV_OPT = 0
  | ( 0 << 2 )  // A-synchronized
  | ( 0 << 3 )  // not static
  | ( 0 << 1 )
  | ( 0 << 0 )  // don't use the fifo
  | ( 0 << 12 ) // set tcc 01  
  | ( 0 << 21 )     
  | ( 1 << 20 )  // inturup enabled, the last TR trigger interupt   
  | ( 1 << 8 )   // 16 BIT FIFO(not be used)
  | ( 0 << 11 );  // each TR one interupt    
 SPIREV_SRC = 0x01C41040 ;
 SPIREV_A_B_CNT = 0x00080002 ;  // 8 group,16 bit
 SPIREV_DST = (Uint32)Adresult;
 SPIREV_LINK_BCNTRLD = 0x0008FFFF ;  //  link to null
 SPIREV_CCNT = 0x00000001 ; // one frame, send once
 SPIREV_SRC_DST_BIDX = 0x00020000 ;

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

EDMA channel configuration for SPI0 Transmit:

 SPITRA_OPT = 0
  | ( 0 << 2 )  //A-synchronized
  | ( 0 << 3 )  //not static
  | ( 0 << 1 )
  | ( 0 << 0 )  //don't use the fifo
  | ( 1 << 12 ) //set tcc 02
  | ( 0 << 21 )
  | ( 1 << 20 )  //inturup  disabled,the last TR trigger interupt   
  | ( 1 << 8 )   //16 BIT FIFO(not be used)
  | ( 0 << 11 );  //each TR one interupt
 SPITRA_SRC = (Uint32)&RANDOM ;
 SPITRA_A_B_CNT = 0x00080002 ;//8 group,16 bit
 SPITRA_DST = 0x01C4103C;
 SPITRA_LINK_BCNTRLD = 0x0008FFFF;  // link to null
 SPITRA_CCNT = 0x00000001 ; //one frame, send once 
 SPITRA_SRC_DST_BIDX = 0x00000000 ;

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

In my program, I make the CPU to wait for the corresponding bit in IPR(EDMA3) being set. As long as the corresponding bit in IPR(EDMA3) is set, the DMA request is disable in the SPIINT0 bit and the SPI0 Receive and Transmit Event is disable in the  EECR bit. Here is the code :

while( (EDMA3CC_IPR & 0x0000003) != 3 );
SPI0_SPIINT0 = 0;
EDMA3CC_EECR = 0xFFFFFFFF;

As your mention, I have finished/expired a PaRAM set and had it configured to Link to NULL , so I have disabled the SPI0 peripheral sending request to the EDMA . But the EDMA still generates a channel controller error interrupt, and this confused me. I don't know whether the error interrupt can be ignored in this case. I have checked the EDMA3CC error registers, the EMR is 0x00008000 and the rest are 0x00000000, which implies that there is a SPI0 Transmit Event missed.

Regards

Liang

Addressed in the other post that you created

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/p/55277/196147.aspx#196147

Regards

Mukul