• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 1082 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

McASP FIFO with EDMA OMAP-L138

Arya Ba
Intellectual 690 points
Other Parts Discussed in Thread: OMAP-L138, OMAPL138

Hi All,

Note: We are using BIOS 5.33.05 / DSPLink 1.65.00.03 on the OMAP-L138 with Linux on the ARM Core.

Memory layout: Data/Program in DDR/L3 with L2/L1D/L1P caching enabled.

I am currently using the McASP bus with the OMAP-L138 connected to several ADC for sampling. Moreover, I have the McASP setup with the FIFO, therefore every HWI i get my 32 samples for every ADC channel. Now, as we continue development we have ran into a issue where the DSP will occasionally miss several HWI. This seems to happen randomly and sporadically making it hard to diagnose. If anymore could shine some light on this it would be great.

I was wondering if we could use the DMA to store N set of 32 samples to reduce HWI frequency and allow for better cache performance in terms of locality. I know the EDMA allows for ping-pong buffering as well, therefore, hypothetically, would we be able to store 256 sets of 32 samples with the EDMA, have the EMDA ping-pong and continue buffering, and issue HWI to CPU for post processing of data ?

Thanks,

Arya B.

  • 0
    TI__Mastermind 35645 points

    Hi Arya,

    Thanks for your post.

    You are right ! Yes, DMA would be the better choice to service the McASP requests through DMA port instead of CPU interrupt service routine in which, XBUF registers  needs to be serviced constantly. If you use DMA to service the McASP, it would take the respective state machinces out of reset and it automatically services the McASP transmit buffer upon receiving AXEVT. As you said, this reduces the interrupt frequency to CPU for servicing McASP transmit data and there could be no chance of missing interrupts by the DSP. This would also enhance the cache performance to have EDMA ping pong and continue buffering tx. data.

    Later, we shall issue interrrupt to CPU only to post process the decoded audio data. This would be the better idea.

    Please refer Section 25.2.4.3.1 & 25.2.4.3.2 for DMA servicing the McASP requests in the OMAPL138 TRM as below:

    http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf

    Thanks & regards,

    Sivaraj K

    ------------------------------------------------------------------------------------------------------- 
    Please click the Verify Answer button on this post if it answers your question.
    --------------------------------------------------------------------------------------------------------
  • 0 in reply to Sivaraj Kuppuraj
    Intellectual 690 points

    Hi Sivaraj,

    Thank you very much for the rapid response, it is very reassuring that we are on the proper path. I just want to clear some details. So the OMAP-L138 EDMA has two sets of 32 channels and 128 PaRAMs. How can I use this to buffer the data from 256 McASP FIFO events before triggering the CPU ? I just want to know conceptually or whether it is possible. 

    Thanks,

    Arya B.

  • 0 in reply to Arya Ba
    Intellectual 690 points

    If anyone could address our aforementioned question we would highly appreciate it. We need to know if it is worth our time to follow through this path.

    Thank you,

    Arya B.

  • 0 in reply to Arya Ba
    Expert 1275 points

    The EDMA can transfer the data from McASP to DDR RAM or shared ram.

    Use channel 0 which corresponds to the capture channel of the ASP (be careful - the DSP framework also uses DMA channels so make sure there are no conflicts. You may also need to tell the linux kernel that the channel is off-limits).

    Set up a cyclic transfer, i.e. use linked params to transfer the data to a larger RAM buffer and use the DMA completion interrupt as a "ping pong" signal. You can also poll the DMA parameters if you want low-latency.

    It may be a lot easier to have the Linux side do this for you though, using ALSA to do the DMA and similar things for you.