• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 100 subscribers
  • Views 288 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.

AM623: TI AM62x BCDMA Questions

Dan Fettke
Prodigy 170 points

Part Number: AM623

Hello,

I was wondering if you could help us out with some questions about BCDMA using the AM62x. We are using QNX 7.1 as our operating system and using BCDMA with interrupts to execute a callback function when the BCDMA transfer is complete. We’re able to use BCDMA to transfer data from the GPMC to RAM successfully, but we have some questions:

  • I’ve been timing different parts of the BCDMA sequence which I’ve pasted below using QNX trace events:
      • Best TRPD Push duration 3us Longest TRPD Push duration 11us Average 4us
      • Best DMA duration 20us Longest DMA duration 40us Average 23us
        • Measured from when the TRPD is pushed to the ring buffer to the time the callback function is executed.
      • Best Completion Callback duration 6us Longest Completion Callback duration 17us Average 6us
        • Pops the TRPD off the completion queue and checks to see if there are any issues.
      • Best TRPD Pop duration 4us Longest TRPD Push duration 9us Average 4us
    • Do you know why there’s such a huge deviation between the shortest and longest duration for these operations?
    • Are these timings what you or your team would expect from these operations?
    • Is it possible to get a better idea of how long just the DMA operation took?
    • If we are using Packet DMA in a different process to handle network traffic, could that have an impact on these timings?
  • How does the completion callback function get executed for QNX? I assume it doesn’t trigger an ISR because we can use mutex lock/unlock, printf, and other ISR unsafe functions, but I believe the DMA is sending an interrupt to the SoC that is being serviced by UDMA.
  • The BCDMA is transferring different lengths of data each time, sometimes as large as 1024 bytes and as small as 4 bytes. An issue I’m seeing is in the case of small transfers the transfer time is much smaller than the callback function execution time.
    • With the same GPMC settings as we use for the larger transfers, can you or your team share any strategies for handling large and small BCDMA transfers?
  • I’ve read that we need to pop the transfer off the completion queue, but for our purposes we don’t care if the DMA was successful or not. Is it possible to not pop transfers off the completion buffer or will that cause issues with BCDMA?

Thanks for yours and your team’s help answering our BCDMA questions.

From,

Daniel Fettke

  • 0
    TI__Genius 14260 points

    Hi Daniel,

    We are looking into this query and will provide feedback asap.

    BR,

    Sunil M S

  • 0
    TI__Expert 4000 points

    Hi Daniel,

    Dan Fettke said:
    • Best TRPD Push duration 3us Longest TRPD Push duration 11us Average 4us
    • Best DMA duration 20us Longest DMA duration 40us Average 23us
      • Measured from when the TRPD is pushed to the ring buffer to the time the callback function is executed.
    • Best Completion Callback duration 6us Longest Completion Callback duration 17us Average 6us
      • Pops the TRPD off the completion queue and checks to see if there are any issues.
    • Best TRPD Pop duration 4us Longest TRPD Push duration 9us Average 4us

    How did you measure the duration of TRPD push and pop? TRPD push is just submitting(writing to register) the TRPD and TRPD pop is just reading the register.
    Do you mean the same ?


    Dan Fettke said:
    How does the completion callback function get executed for QNX? I assume it doesn’t trigger an ISR because we can use mutex lock/unlock, printf, and other ISR unsafe functions, but I believe the DMA is sending an interrupt to the SoC that is being serviced by UDMA.

    Once the transfer is done completely, DMA will interrupt the soc and interrupt can be serviced.

    Dan Fettke said:
    I’ve read that we need to pop the transfer off the completion queue, but for our purposes we don’t care if the DMA was successful or not. Is it possible to not pop transfers off the completion buffer or will that cause issues with BCDMA?

    Yes, we need to pop  from completion queue,otherwise the cq overflow might occur and resulting in the failure of further transfers.

    Regards,
    Vaibhav

  • 0 in reply to Vaibhav Reddy
    Prodigy 170 points

    Dear Vaibhav,

    Thank you for your reply!

    I'm measuring these timings by putting a QNX TraceEvent around areas of code I want to time, then measuring the time between Trace Events after getting the QNX trace logger file: TraceEvent(). Pushing the TRPD is done with the TI API Udma_ringQueueRaw, and popping the TRPD off the completion queue is done with Udma_ringDequeueRaw. Is it suggested we should directly read or write to the appropriate UDMA registers instead of using the TI APIs? What cases might account for the worse case times?

    With regards to the interrupt, what type of interrupt does the UDMA driver use? Is it an ISR, IST, or something else?

    We are interested in using SUPR_EVT and Reload Count to prevent the TRPD from populating the completion queue and prevent a callback function from being called, and rely on alternatives to determine when the BCDMA was complete. Are there any considerations or risks with SUPR_EVT and Reload Count?

    I have some additional questions that my team has thought of since opening this case. What happens when Udma_ringQueueRaw gets called? To my understanding the TRPD gets pushed to a ring buffer pointed to by chPrms.fqRingPrms.ringMem and the queue is managed by the UDMA driver, then the forward doorbell is "rung". Is that correct? At what point does the data in ringMem get written to the UDMA registers so the DMA itself knows where to transfer data to and from and how much data to transfer? If we use indirection (TR_ISA or TR_IDA) for our source and destination addresses, when will those addresses be read by the UDMA?

    From,

    Daniel Fettke

  • 0 in reply to Dan Fettke
    TI__Expert 4000 points

    Hi Daniel,

    Dan Fettke said:
    Is it suggested we should directly read or write to the appropriate UDMA registers instead of using the TI APIs? What cases might account for the worse case times?

    Direct read or write to appropriate UDMA registers is no recommended, use TI Api's.

    Dan Fettke said:

    With regards to the interrupt, what type of interrupt does the UDMA driver use? Is it an ISR, IST, or something else?

    UDMA driver uses ISR.

    Dan Fettke said:
    What happens when Udma_ringQueueRaw gets called? To my understanding the TRPD gets pushed to a ring buffer pointed to by chPrms.fqRingPrms.ringMem and the queue is managed by the UDMA driver, then the forward doorbell is "rung". Is that correct?

    Yes,When the Udma_ringQueueRaw is called the TRPD is pushed to the ring.

    Dan Fettke said:
    At what point does the data in ringMem get written to the UDMA registers so the DMA itself knows where to transfer data to and from and how much data to transfer?

    Udma_ringQueueRaw is responsible for submitting the TRPD and initiating the transfer.Lets say if one transfer is going on and we submit another one, second one will not start until first one finishes.


    Dan Fettke said:
    If we use indirection (TR_ISA or TR_IDA) for our source and destination addresses, when will those addresses be read by the UDMA?

    You can refer Block copy operation section(11.1.4.16) in the TRM which provides more info on this.

    Regards,
    Vaibhav

  • 0 in reply to Vaibhav Reddy
    Prodigy 170 points

    Dear Vaibhav,

    Thanks for your reply. I've been doing some digging since my last question and based on some pidin output it looks like UDMA is creating an IST with the prefix "IntrThread_" in HwiP_create. This thread is causing a QNX shutdown for us, so I'm trying to debug what isr_thread is doing and why it would be causing a shutdown. 

    We are also investigating using SUPR_EVT so the completion callback function does not get called and ideally IntrThread_ does not get created to not only improve the performance of our use case but also to prevent this QNX shutdown from happening. If we set CSL_FMK(UDMAP_TR_FLAGS_SUPR_EVT, 1U), are there any additional steps needed for UDMA_EVENT_TYPE_DMA_COMPLETION events? Do we need to set up a completion event, or should eventCb be set to NULL?

    From,

    Daniel Fettke