• State Answer Suggested
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 1537 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.

C674x McBSP with FIFO and DMA delay

Bhaskar Reddy
Intellectual 980 points

We have configured McBSP to use FIFO and linked EDMA to handle the transfers. Buffer size is 64 byte. Data transfer is happening between two c674x processors. No loss of data or errors observed in communication.

Configuration is : Frame sync at every 130usec. Data occupies 80usec between two frame syncs (all 64 bytes gets transmitted in 80usec)

EDMA configured to copy 64bytes for 1 event.

But, there is a delay between, when the packet is originated and when the same packet received. And this delay is more than expected.

Expected delay is 260 +/- 50usec. But actual delay is observed to be around 800usec.

This delay is measured in EDMA isrs in each DSP by triggering signals on GPIOs of each processor.

My conclusion is that, its FIFO is causing this delay.

Here FIFO size is 256 bytes, WNUMEVT is 64 bytes. 

When an EDMA event occurs, it copies set of 64 bytes to McBSP, but McBSP FIFO has 192 bytes (256-64) in its queue which before this new set can go out of McBSP.

To verify this: I disabled FIFO in McBSP and reconfigured EDMA. Delays are as expected.

Now the question is, how to avoid this delay when FIFO is enabled in McBSP.

  • 0
    Mastermind 6115 points
    Hi Bhaskar,

    We are working on it. Will update you soon.
    Thanks for your patience.

    Please provide following information.
    1. Are you working on TI EVM or custom board?
    2. Are you working with TI provided Example code or your own developed code?
  • 0
    Mastermind 6115 points
    Hi Bhaskar,

    Please check out below mentioned query which may help you out .
    Please try out with the suggestions given in this post, hope they will help you out to reduce the unexpected delay.

    e2e.ti.com/.../60093
  • 0 in reply to Arvind Singh
    Intellectual 980 points

    Hi Arvind,

    Thanks for your replies.

    I'm not using any library or example code.

    I have seen the link that you gave, before I posted my query.

    My concern is about the delay introduced by the FIFO when FIFOs are enabled with McBSP and EDMA. I didn't find any method to avoid this additional delay introduced by FIFO.

    I just disabled FIFO as the delay is not acceptable.

    I wanted clarification on whether the delay introduced by FIFO is normal and as per the design or am I missing something.

    To explain the delay in detail:

    Configure WNUMEVT to 8 bytes and FIFO size is 256 bytes.

    Configure Frame sync 1ms with 8 bytes out every frame sync.

    With above configuration, expectation is, when a 8 byte packet is written in EDMA ISR at source DSP then it would take worst case 2ms to see the packet at destination DSP. 

    But the observation is it may take 33msec to see that packet at destination.

    The reason is :

    0th msec : When McBSP/ EDMA enabled with above configuration, in the beginning itself it generates 32 events and fills the FIFO (even before the first set of 8 bytes go out).

    1st msec: EDMA completes 8 bytes of data. This results in EDMA event because the space now available in FIFO is >= WNUMEVT. EDMA ISR writes data in to buffer. 

    But the data written at 1st msec instance takes 32msec to reach destination because there 248 bytes are in queue before this new set can bu put on to McBPS TX line.

    Let me know if my understanding is correct.

  • 0 in reply to Bhaskar Reddy
    Mastermind 6115 points
    Hi Bhaskar,

    Your understanding was not correct. As you have configured 8bytes per event.

    Configure WNUMEVT to 8 bytes and FIFO size is 256 bytes.

    So it will fill FIFO with 8bytes after every event, and will transfer 1 word(4bytes) at a time if we will configure WNUMDMA =1 word.
    You can read WLVL bit of WFIFOSTS (write FIFO status register), and can verify how many bytes are written into the FIFO.

    BFIFO adds extra tolerance and DMA controller response times may vary ,depend on different conditions.
    So we cannot predict exact time that packet transfer will take to reach at the receiver end.

    1. Have you checked (X/R)DATDLY bit of (X/R)CR Register. You can configure this delay to 0 in transmit/receive control register.
    2. You can increase frame frequency by decreasing time between frame synchronization signals.
    Check section 2.7.3(Maximum frame frequency) of McBsp user-guide(sprugj6c).
  • 0 in reply to Arvind Singh
    Intellectual 980 points

    Hi Arvind,

    Thanks for your reply.

    I'm still not able to understand on how to use FIFO without causing delay.

    As an example, Lets say  Source side DSP generates 8 bytes of data for every 1msec. So I configured DMA to take these 8 bytes and give it to McBSP. And McBSP Frame sync configured to occur every 1ms to take this data out and give to Receive side DSP.

    Lets now try to answer below questions:

    Please read this statement from section 23.2.7.6.1.1 of spruh80a

    "If the Write FIFO has space to accept WNUMEVT 32-bit words, it generates a transmit DMA request to  the host and then waits for a response "

    Question is, after enabling McBSP, how many DMA events it will generate with WNUMDMA = 1 and WNUMEVT = 8 (FIFO size 256)? My answer is 32 events till FIFO gets full. All these 32 events get generated before even first 8 bytes are transmitted out of FIFO.

    But Source side DSP has only 8 bytes of data. What to do with 31 more events generated in the beginning itself. How to block these 31 events which are happening in the beginning itself.

    In  this case, same data will be filled for all the 32 events. 

    Now after first set of 8 bytes moved out of FIFO, DMA event is generated and now new data moved to FIFO. Before this new data there are 248 bytes already in  FIFO which got in first with above 31 events. As McBSP configured to move data out ever 1ms, its going to take 31ms before my new data is received at Reciever side DSP. This is the delay that I'm talking about.

    This delay is defined as : 

    Time taken from the point a set of WNUMEVT bytes written in to FIFO to the time those bytes started clocked out on McBSP port. 

    This delay = Time taken by  McBSP to take out (256-WNUMEVT) bytes from from FIFO.

    Reason for this delay:

    FIFO handler tries to keep the FIFO always full and there is no way to configure the depth of FIFO to control when to generate event so that this delay can be adjusted.

  • 0 in reply to Bhaskar Reddy
    Mastermind 6115 points
    Hi Bhaskar,

    Question is, after enabling McBSP, how many DMA events it will generate with WNUMDMA = 1 and WNUMEVT = 8 (FIFO size 256)? My answer is 32 events till FIFO gets full. All these 32 events get generated before even first 8 bytes are transmitted out of FIFO.

    Yes. It will generate 32 events.

    Please read this statement from section 23.2.7.6.1.1 of spruh80a
    "If the Write FIFO has space to accept WNUMEVT 32-bit words, it generates a transmit DMA request to the host and then waits for a response "

    It depends on your data how many bytes of data you want to transfer. It will generate events on that basis.

    For example we want to transfer 40 bytes.

    At the start 40 bytes are in queue and waiting to be transferred.
    We have configured WNUMEVT= 2h ( 2 words ) Which is equal to 8 bytes and WNUMDMA = 1.
    For 1st time an event will be generated and 8 bytes will be written into FIFO and it will not wait for words( 8 bytes ) to be transferred from Write FIFO to the McBSP as write FIFO is having sufficient space to write more words, so again it will generate 1 more event and it will write 8 more bytes into WRITE FIFO. In the meantime data will be transferred from WRITE FIFO to the McBSP , and process will go on.
    So all together it will generate 5 events.

    Waiting condition will come into picture when WRITE FIFO is full(i.e 256 bytes are occupied), till the time WNUMEVT space is not free in WRITE FIFO it will wait, and soon as it WNUMEVT space is available it will generate an event.

    Now after first set of 8 bytes moved out of FIFO, DMA event is generated and now new data moved to FIFO. Before this new data there are 248 bytes already in FIFO which got in first with above 31 events. As McBSP configured to move data out ever 1ms, its going to take 31ms before my new data is received at Receiver side DSP. This is the delay that I'm talking about.

    So here what i can suggest you is try to configure WNUMEVT = 32 or 64, with this configuration, 2 event will be generated for WNUMEVT and 1 event will be generated for WNUMEVT=64.
    In this way FIFO will also be fully occupied and frame sync will also be less, check whether delay is reduced or not.
  • 0 in reply to Arvind Singh
    Intellectual 980 points

    Arvind Singh said:

    For example we want to transfer 40 bytes.

    At the start 40 bytes are in queue and waiting to be transferred.
    We have configured WNUMEVT= 2h ( 2 words ) Which is equal to 8 bytes and WNUMDMA = 1.
    For 1st time an event will be generated and 8 bytes will be written into FIFO and it will not wait for words( 8 bytes ) to be transferred from Write FIFO to the McBSP as write FIFO is having sufficient space to write more words, so again it will generate 1 more event and it will write 8 more bytes into WRITE FIFO. In the meantime data will be transferred from WRITE FIFO to the McBSP , and process will go on.
    So all together it will generate 5 events.


    Lets use your example only. Assume McBSP clock speed is 100kHz (so @ 10usec per bit, it takes 80usec for a byte and 640usec for 8 bytes).

    With 256 bytes of FIFO, it generates 32 events, even before 1st word is moved out of FIFO (which takes 320usec) . I didn't get why you are saying, it generates only 5 events. We know that we have only 40 bytes to send, but after writing 40 bytes with 5 events, McBSP continues to give events (till FIFO gets full). How to stop these events. If I configure to use EDMA, how can I stop EDMA response to these events. My next set of 40 bytes will be ready only after the previous 40 bytes are sent out.