• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 100 subscribers
  • Views 448 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.

A EDMA programing issue.

Yulin
Expert 1625 points

Hi TI experts,

Given that EDMA QUEPRI=0x0111 and only McBSP_TX event is routed to TC3.
All other bandwidth associated registers are default valued.
This application is a video recorder with the following combination:

Thread priority

 EDMA TC Task description
0 TC2 audio encoder, AAC by ARM
1 TC2 video encoder, VPFE to DRAM and H264VENC by HDVICP
2 TC2 file writer to SD card by ARM
3 TC2

video analyzer
image captured by EDMA (DRAM-to-DRAM) and analyzed by ARM

 

 

 

 

 

 

First I noticed the recorded audio sounds weird and put McBSP RX to TC3, the audio is right.
If McBSP RX is kept in TC2, the audio is also right by disabling the EDMA in video analyzer.

Following I test the application with a SD card of large cluster, EDMA timeout occurs for SD R/W.
To confirm it is a bandwidth issue,
again I disable the EDMA in video analyzer, luckily no SD card EDMA timeout occurs.

Image is 640x480 in YUV422.
Current EDMA setting is ACNT=1280, BCNT=480, CCNT=1, and ABSYNC.
Actually, only Y is needed by video analyzer.
Please suggest a more efficient EDMA programming to make the whole app right.

Thanks & regards,
Yulin.

  • 0
    Guru 31670 points

    Yulin,

    From your description and the given use case, I don't think bandwidth limitation is the cause of the issue. It looks to me like the EDMA parameters are getting corrupted when you are running two things simultaneously. Can you check whether the EDMA parameters are getting corrupted, by dumping the EDMA registers.

  • 0 in reply to Renjith Thomas
    Expert 1625 points

    Renjith,

    I reviewed the PaRAMs, all are right.

    In the McBSP case, it really looks like a bandwidth issue.

    May I know your idea for the inference?

    BR,

    Yulin.

  • 0 in reply to Yulin
    Guru 31670 points

    Yulin,

    The total memory load is not so much when compared to what DM36x can handle. It can do video encoding upto 1080p30. And there is no audio issue in this use case. Do you have a calculation for the bandwidth requirement for your use case?

    Alternatively you can try to alter the EDMA transfer controller burst size in the "MISC" register in system controller.  There are two burst sizes, 32 byte and 64 byte. Try these two values and see whether any difference in performance is there or not. If its there, then I agree with you that it could be a bandwidth issue. 

  • 0 in reply to Renjith Thomas
    Expert 1625 points

    Renjith,

    Finally, it is a side-effect far from the true reason that a mutex (not EDMA-related) dead lock should be fixed.

    Thanks & regards,

    Yulin.