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.

EDMA channels priority on OMAPL138

Other Parts Discussed in Thread: OMAP-L138

Dear E2E:

Thank you for your support.

I posted this question ~3 weeks ago but did not get the answer yet. Can you please respond on this EDMA channels priority question?

1.  I need to use EDMA for data transfer from McASP and SPI0.

2.  I was able to setup EDMA for McASP and SPI0 - they run OK.

3.  SPI0 has CLK rate of ~36.9MHz and set for 16-bit character length.

4.  The 16-bit character need to be serviced by EDMA every ~0.434uS.

5.  I can see that SPI0 EDMA readings became incorrect when McASP is serviced by EDMA simultaneously with SPI0.

6.  McASP uses a FIFO which needs to be serviced by EDMA every 15.25uS.

7.  That means - SPI0 (EDMA channel_14) must have the higher priority than McASP (EDMA channel_0).

8.  But according to the UM, page 596 "for EDMA events, channel_0 has the highest priority and channel_31 has the lowest priority"

9.  How can I change the EDMA channel_0 and EDMA channel_14 priority?

Thank you for your help,

Boris Ruvinsky

 

  • Boris,

    Sorry for the delay, hope you had a good holiday.  A collegeue and I looked through the TRM and determined how we can change the priorities of the DMA events.  As you've experienced, without additional configuration, DMA events will be serviced based on their event ID.

    However, you can invert the priorities of two simultaneous events by selecting which queue they go in to.  An event can be placed into one of two queues (q0 or q1).  Q0 is the default.  As you'd expect, q0 has priority over q1.  So you can follow that if you put event 0 into q1, and event 14 into q0, you have successfully inverted their priorities. 

    Please go to page 630 of the OMAP-L138 TRM to learn how to set this up: http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf

    You'll want to set bit 0 of DMAQNUM0 to 1 and bit 24 to 0 of DMAQNUM1 in your case: 

     

    We hope this helps!

    Mike and Alexa @ TI

  • Thank you for your help,

     

    Boris Ruvinsky

  • Hello Michael.

    Thank you again for your respond and help.

    But unfortunately - the settings of DMAQNUM registers as described in your respond are not sufficient for making system work.

    I have the following settings:

    1.  I set DMAQNUM0 = 0x11111111 - all '1' even I really use EDMA events E0, E2, E4

    2.  I set DMAQNUM1 = 0x00111111 - "00" for events E15:E14 (SPI0) and all others are '1'

    3.  I set also  SYSCNFG_MSTPRI1 = 0x00011000 to make sure EDMA30TC0 has higher (0) priority than  EDMA30TC1 (1).

    4.  The system behavior did not change at all after these settings. The SPI0 events E15:14 are getting missed and buffers are getting corrupted.

    5.   SPI0 port is running at ~36MHz and set to 16-bit character length - so it must be serviced by EDMA every ~450nS. Is this OK for EDMA?

    6.  This works OK when SPI0 is the only active master.

    7.  As soon as other masters (McASP, McBSP0, McBSP1) become active - the SPI0 events E15:E14 are getting missed. But this is not shown in EMACC0 EMR register.

    8.  Can you please give the recommendations what can be done to set the right priority for EDMA events?

    I worked on the different prototyping issues and now is back to the EDMA priorities which is very important for us to resolve.

    Thank you for your help,

    Boris Ruvinsky

    802-877-4978

  • Hello Michael.

    Thank you for your support.

    1.  I enabled ITCCHEN for McASP port but McASP became unstable after that - even when it runs along.

    2.  How this McASP behavior can be explained? McASP generate EDMA event every ~15.26uS which is not so fast? Why setting ITCCHEN=1 make McASP EDMA unstable - like it is missing some data?

    3.  But EMR register is not set.

    4.  I can open new post for this issue if it can help to get the answer faster.

    Thank you very much for your help,

    Boris Ruvinsky