• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 345 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.

Strange DM644x DMA QUEPRI behavior with CodecEngine algorithm

David Kondrad
Prodigy 80 points

Greetings,

 

We have a strange issue with the DMA QUEPRI register being reset to TI defaults (T0: priority 3,  T1: priority 7) every time we call the eVRU video display algorithm.

The register is being set to the defaults regardless of what has specified for the DMAN3.queuePri array (which works fine up until we call the algorithm).

The fact that the values are the TI DMAN3 defaults is suspicious to me.

I've looked at the codec stub source and it looks like they are using DMAN3, ACPY3, and QDMA.

 

We are using Codec Engine 2.10.01 package + MV 2.6.10 kernel.

The issue existed to some extent on the 1.3 silicon revision, but it was not severe enough to stop our push for production units.

Now that our manufacturer has run out of old revision and started using the 2.1 PG revision chips, the problem is so severe that we cannot ship out our products.

 

Is it possible that there's a bug in one of these that do not use the specified values or is it more likely the codec itself is doing something?

 

The symptoms of this are EDMA missed events being trapped by the error interrupt handler on the ARM side which leads to any one of the following:

1. EMAC transfer errors

2. MMC/SD card missed events and subsequent lockups

3. McASP missed deadlines which shift the samples or lock ups

... basically, anything that relies on EDMA to complete in any reasonable deadline is being hosed eventually.

 

If anyone has seen this issue before, feel free to chime in!

 

Regards,

David

 

  • 0
    TI__Expert 7415 points

    Hi David,

    What platform are you running your application on ?! (ARM or DSP ?)

    The values you see are indeed those set up by DMAN3 as defaults. However, DMAN3 simply "ORs" these values into already existing values in the QUEUEPRI register. If you would like DMAN3 not to alter these values, please override these values in your cfg file as follows:-

    var DMAN3 = xdc.useModule("ti.sdo.fc.dman3.DMAN3");

    DMAN3.queuePri = [0,0,0,0]; //It would "OR" zeroes into the register, leaving the original values in etc */

     

    I don't understand what you mean by these values reverting to the defaults (3,7,0,0) everytime you "call" the algorithm. These values are set at the time DMAN3 is initialized, which means whenever CERuntime_init() is called from the "main()" in your application

    (CERuntime_init -> Algorithm_init -> DMAN3_init -> initializes QUEUEPRI register only the first time that DMAN3 is called).

    Please let me know if your observations are consistent with the above.

     

    Thanks,

    Gunjan

  • 0 in reply to Gunjan
    Prodigy 80 points

    Greetings,

     

    Thanks for the reply.

    That's good information to know that it ORs values... nowhere that I saw was that stated in the docs.

    Anyways...

     

    Using some deductive debugging involving map files, Code Composer, and tracing DSP asm, I actually traced it down to the eVRU codec.

    Inside one of their algorithm initializers they were writing a hard-coded 0x73 to the QUEPRI register which overwrote the value stored by DMAN3.

     

    The proper solution would be for TES (who owns eVRU) to not mess with those settings at all (like XDM spec states), but since we're on a tight deadline, I chose to hunt down the MVK.S assembly instruction and replace the immediate value with 0x10 instead of 0x73!

    I've verified that our server image now has a QUEPRI of 0x10 and things are looking good.

     

    Hopefully others will see this and check their dma settings if they have any odd behavior... maybe a register change is all they need.

    Thanks again for the help!

    -- David

    "No source, no problem!"

     

  • 0 in reply to David Kondrad
    TI__Genius 17205 points

    Glad you tracked this down, and thanks for posting your findings!

    I was afraid it was a codec-specific issue.  Please be sure to file a bug with the eVRU codec owners - that's a clear XDAIS violation they should fix.

    Chris