• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 99 subscribers
  • Views 366 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.

Missing first bytes of EDMA / McBSP transfer

Dan Crutcher
Prodigy 10 points

I have an 840 byte buffer of data that I am DMAing to the McBSP1 TX on a C6424 for output to an external device.  The clock rate to the McBSP is set to 6 Mhz and the transfer occurs about every 2 milliseconds so there is no issue with having enough time to transfer the data.  Most of the time there is no problem with sending the data, however, approximately 10% of the time the first 4 (sometimes 8) bytes of the data do not get transferred.  It feels like in the cases where data is missing that the McBSP is just not ready to transmit at the time of the first word(s) of the DMA.  I have tried several experiments to resolve the issue.  Some experiments have reduced the number of buffers that are corrupted but none completely solved the problem.

Experiments:

1) while( ! ( MCBSP1_SPCR & MCBSP_SPCR_XRDY) );  prior to triggering the DMA seemed to help quit a bit.

2) placing the buffer in non-cached IRAM did not help at all

3) disabling interrupts around the trigger helped.
           

Thanks in advance for any possible ideas.

 

  • 0
    TI__Guru* 84110 points

    Dan Crutcher said:
    840 byte buffer of data ... clock rate 6 Mhz ... "about" every 2 milliseconds ... no issue with having enough time

    My calculator says you need 56% of 2 ms to transfer the data. If "about 2 ms" means 1.75 ms, then you need 64% of the time. I do not know what you have to do between transfers of 840-byte blocks, and I do not know how you have the McBSP configured for maximizing throughput, but we could find scenarios where DSP CPU load and memory bus load eat up that pad - it all depends on how you are doing this. You might want to look at the FSXn and DXn signals w.r.t. the target timing to make sure you are staying within realtime constraints.

    Hopefully, you are using DMA channel 2 or 4 to send your data, and only triggering it manually to get the first one started.

    Dan Crutcher said:
    1) while( ! ( MCBSP1_SPCR & MCBSP_SPCR_XRDY) );  prior to triggering the DMA seemed to help quit a bit.

    Conversely, if you are triggering the DMA to start sending data when XRDY=0, you can expect to lose some data. The fact that this helped implies that you are not staying within realtime constraints.

    Dan Crutcher said:
    3) disabling interrupts around the trigger helped.

    This implies that the system is loaded pretty heavily, or that something in one of your interrupts is affecting something in your McBSP code that is non-reentrant.

    Dan Crutcher said:
    Thanks in advance for any possible ideas.

    1. Classically, the first transfer can be started at anytime after the McBSP has been initialized. The McBSP User's Guide should tell you if you need to trigger it manually or not, for that first transfer. After that, the McBSP will keep asking for more data by triggering the XRDY EDMA event.
    2. These XRDY triggers will go on forever. If you need to stop the transfers because you have run out of data in the buffer, you need to terminate the DMA channel in some way. You do not want to terminate by linking to a NULL PARAM set because this will lead to EDMA error conditions; look at the EDMA SER and EMR registers and make sure no bits are set, something went wrong if there are. Instead, either link to a DUMMY PARAM set (see EDMA User's Guide) or link to a fake data PARAM set that will send out data to be ignored; the choice here depends on what the target requires.
    3. When you are ready to start the next buffer going out at the next 2ms point, make sure XRDY=1.
    4. It seems odd to me that disabling interrupts affects this. Maybe you should move the interrupt disable window around to find out exactly where it makes a difference. Then figure out what is happening in that interrupt that is hurting your McBSP restart.
  • 0
    TI__Guru*** 125430 points

    Which device is the master?  The EDMA should be configured prior to the McBSP.  You should not be manually triggering the EDMA.  When you take the McBSP transmitter out of reset it will send an event to the EDMA immediately.