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.

ACPY3_activate hangs in the DSP when called

Hello,

I'm trying to use DMAN3 and ACPY3 to perform DMA transfers in the DSP. I've followed the VIDENC_COPY example but my code hangs when ACPY3_activate is called. With CE_DEBUG=3, I also noticed I did not see any output from the DMAN3_init() or ACPY3_init(). Just to verify I had debugging/trace turned on, I added DMAN3_init() and ACPY3_init() to my algorithms _alloc() call, and I did see the calls now to the "init"s in the CE_DEBUG trace. This did not change the resulting hang in the ACPY3_activate() call.

I have assumed that DMAN3_init() and ACPY3_init() gets called by Codec Engine when I call CERuntime_init(), is that correct? Does anyone have an idea why I don't see the calls to DMAN3_init() and ACPY3_init() in my CE_DEBUG trace? Or more importantly, does anyone know why this hang is occurring?

Below is my configuration of the server and I've attached my CE_DEBUG trace.

xdc.useModule("ti.sdo.fc.global.Settings").profile = "debug";
xdc.loadPackage("ti.sdo.fc.dman3").profile = "debug_trace";
xdc.loadPackage("ti.sdo.fc.acpy3").profile = "debug_trace";

/* establish dependency on the ALG package */
xdc.loadPackage("ti.sdo.fc.utils.api");

var DMAN3 = xdc.useModule('ti.sdo.fc.dman3.DMAN3');
var ACPY3 = xdc.useModule('ti.sdo.fc.acpy3.ACPY3');

DMAN3.heapInternal    = "IRAM";       /* L1DHEAP is an internal segment */
DMAN3.heapExternal    = "DDRALGHEAP";
DMAN3.idma3Internal   = false;
DMAN3.scratchAllocFxn = "DSKT2_allocScratch";
DMAN3.scratchFreeFxn  = "DSKT2_freeScratch";

DMAN3.paRamBaseIndex     = 80;  // 1st EDMA3 PaRAM set available for DMAN3
DMAN3.numQdmaChannels    = 8;   // number of device's QDMA channels to use
DMAN3.qdmaChannels       = [0,1,2,3,4,5,6,7]; // choice of QDMA channels to use
DMAN3.numPaRamEntries    = 48;  // number of PaRAM sets exclusively used by DMAN
DMAN3.numPaRamGroup[0]   = 48;  // number of PaRAM sets for scratch group 0
DMAN3.numTccGroup[0]     = 32;  // number of TCCs assigned to scratch group 0
DMAN3.tccAllocationMaskL = 0;          // which TCCs  0..31 for DMAN3
DMAN3.tccAllocationMaskH = 0xffffffff; // which TCCs 32..63 for DMAN3

0842.ce_debug_output.txt

  • Also, I am on a DM6467 with bios version 5_41_00_06 and framework component version 2_25_02_06

  • I have copied over the videnc1_copy codec example and have compiled that into my server to see if I can get this TI example running. It hangs in the ACPY3_start() call. I also get some ASSERTIONS in the ACPY3_activate() and ACPY3_configure calls. An output of the CE_DEBUG trace is shown below. I've commented out the ACPY3_start() call so it wouldn't hang. It appears my DMA handle is NULL.

    I don't know why the DMA handle is NULL? Shouldn't DMAN3 lib be populating this in the codec engine? I'm assuming all initialization is done by the codec engine. Any help is greatly appreciated, I'm struggling here.

     

    [DSP] @0,273,370tk: [+0 T:0x8fa053a4 S:0x8fa07924] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Enter (handle=0x8fa04f40, inBufs=0x8fa079c4, outBufs=0x8fa07a94, inArgs=0x8fe04a04, outArgs=0x8fe04a10)
    [DSP] @0,273,550tk: [+5 T:0x8fa053a4 S:0x8fa07904] CV - VISA_enter(visa=0x8fa04f40): algHandle = 0x8fa04f78
    [DSP] @0,273,676tk: [+0 T:0x8fa053a4 S:0x8fa078e4] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Enter(alg=0x8fa04f78)
    [DSP] @0,273,801tk: [+0 T:0x8fa053a4 S:0x8fa078ac] ti.sdo.fc.dskt2 - DSKT2_activateAlg> Enter (scratchId=0, alg=0x88000000)
    [DSP] @0,273,936tk: [+2 T:0x8fa053a4 S:0x8fa078ac] ti.sdo.fc.dskt2 - DSKT2_activateAlg> Last active algorithm 0x88000000, current algorithm to be activated 0x88000000
    [DSP] @0,274,085tk: [+2 T:0x8fa053a4 S:0x8fa078ac] ti.sdo.fc.dskt2 - DSKT2_activateAlg> Activation of algorithm 0x88000000 not required, already active
    [DSP] @0,274,225tk: [+0 T:0x8fa053a4 S:0x8fa078ac] ti.sdo.fc.dskt2 - DSKT2_activateAlg> Exit
    [DSP] @0,274,332tk: [+0 T:0x8fa053a4 S:0x8fa078e4] ti.sdo.ce.alg.Algorithm - Algorithm_activate> Exit
    [DSP] ASSERTION ERROR: assertion violation: acpy3_qdma.c, line 82
    [DSP] @0,274,488tk: [+0 T:0x8fa053a4 S:0x8fa0786c] ti.sdo.fc.acpy3 - ACPY3_activate> Enter
    [DSP] @0,274,596tk: [+2 T:0x8fa053a4 S:0x8fa0786c] ti.sdo.fc.acpy3 - ACPY3_activate> Copy env 1176608 byte from persistent 0x8f8e8694 to scratch 0xffee0bff
    [DSP] @0,330,938tk: [+2 T:0x8fa053a4 S:0x8fa0786c] ti.sdo.fc.acpy3 - ACPY3_activate> Qdma channel = 0
    [DSP] @0,331,073tk: [+2 T:0x8fa053a4 S:0x8fa0786c] ti.sdo.fc.acpy3 - ACPY3_activate> QCHMAP register for this channel is 0xffffffff
    [DSP] @0,331,206tk: [+2 T:0x8fa053a4 S:0x8fa0786c] ti.sdo.fc.acpy3 - ACPY3_activate> QEER register for this channel is 0x8fab31bc
    [DSP] @0,339,016tk: [+4 T:0x8fa053a4 S:0x8fa0786c] ti.sdo.fc.acpy3 - ACPY3_activate> numPaRams 31380, numTccs 0
    [DSP] @0,339,136tk: [+0 T:0x8fa053a4 S:0x8fa0786c] ti.sdo.fc.acpy3 - ACPY3_activate> Exit
    [DSP] @0,339,242tk: [+4 T:0x8fa053a4 S:0x8fa078bc] INSIGHT - VIDENC1COPY_ADSYS_process(): videncObj->dmaHandle1D1D8B->env = 0x8fa05384
    [DSP] @0,339,372tk: [+4 T:0x8fa053a4 S:0x8fa078bc] INSIGHT - VIDENC1COPY_ADSYS_process(): counter = 1
    [DSP] ASSERTION ERROR: assertion violation: acpy3_configure.c, line 82
    [DSP] ASSERTION ERROR: assertion violation: acpy3_configure.c, line 83
    [DSP] ASSERTION ERROR: assertion violation: acpy3_configure.c, line 89
    [DSP] @0,339,601tk: [+0 T:0x8fa053a4 S:0x8fa0786c] ti.sdo.fc.acpy3 - ACPY3_configure> Enter (handle=0x0, transferNo=0)
    [DSP] @0,339,725tk: [+4 T:0x8fa053a4 S:0x8fa0786c] ti.sdo.fc.acpy3 - ACPY3_configure> 1D1D transfer
    [DSP] @0,339,839tk: [+4 T:0x8fa053a4 S:0x8fa0786c] ti.sdo.fc.acpy3 - ACPY3_configure> src 0x9e898000, dst 0x9e8ae000, acnt 0x400, bcnt 0x1
    [DSP] @0,339,974tk: [+4 T:0x8fa053a4 S:0x8fa0786c] ti.sdo.fc.acpy3 - ACPY3_configure> bcnt reload 0x1, srcIndex 0x1, dstIndex 0x0
    [DSP] @0,340,105tk: [+2 T:0x8fa053a4 S:0x8fa0786c] ti.sdo.fc.acpy3 - ACPY3_configure> Tcc 116
    [DSP] @0,340,219tk: [+4 T:0x8fa053a4 S:0x8fa0786c] ti.sdo.fc.acpy3 - ACPY3_configure> Link this transfer to 0x319c Opt is 0x174004
    [DSP] @0,340,356tk: [+5 T:0x8fa053a4 S:0x8fa07904] CV - VISA_exit(visa=0x8fa04f40): algHandle = 0x8fa04f78
    [DSP] @0,340,492tk: [+0 T:0x8fa053a4 S:0x8fa078e4] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Enter(alg=0x8fa04f78)
    [DSP] @0,340,622tk: [+0 T:0x8fa053a4 S:0x8fa078bc] ti.sdo.fc.dskt2 - DSKT2_deactivateAlg> Enter (scratchId=0, algHandle=0x88000000)
    [DSP] @0,340,757tk: [+4 T:0x8fa053a4 S:0x8fa078bc] ti.sdo.fc.dskt2 - DSKT2_deactivateAlg> Lazy deactivate of algorithm 0x88000000
    [DSP] @0,340,886tk: [+0 T:0x8fa053a4 S:0x8fa078bc] ti.sdo.fc.dskt2 - DSKT2_deactivateAlg> Exit
    [DSP] @0,340,994tk: [+0 T:0@0,452,241us: [+0 T:0x4001ed90 S:0xbee197a4] OC - Comm_put> Enter(queue=0x0, msg=0x41377880)
    @0,452,741us: [+0 T:0x4001ed90 S:0xbee197a4] OC - Comm_put> return (0)
    @0,453,542us: [+0 T:0x4001ed90 S:0xbee1979c] OC - Comm_get> Enter(queue=0x10000, msg=0xbee1983c, timeout=-1)
    @0,453,933us: [+0 T:0x4001ed90 S:0xbee1979c] OC - Comm_get> MSGQ_get() status=0x8000, return (0)
    x8fa053a4 S:0x8fa078e4] ti.sdo.ce.alg.Algorithm - Algorithm_deactivate> Exit
    [DSP] @0,341,114tk: [+0 T:0x8fa053a4 S:0x8fa07924] ti.sdo.ce.video1.VIDENC1 - VIDENC1_process> Exit (handle=0x8fa04f40, retVal=0x0)

  • What is the version of Codec Engine you are using (from where you copied the videnc1_copy example ) ?

    When you copied that example, did you also copy the server config file from the same example ? 

    Thanks,
    Gunjan. 

  • Gunjan,

    Thanks for your reply! I'm using DVSDK 3.10.00.19 with Codec Engine 2.25.05.16 (as it came with the dvsdk).

    I'm trying to follow a development path using the codec engine wizards in linux. So I ran the GenCodecPkg wizard to generate a shell algorithm based on base interface IVIDENC1. Then I used the GenServer wizard to create a codec server that contained my algorithm. I compiled all this and ran a linux app to call it and everything worked. This was just using a memcpy though. I verifed it worked though.

    Then I added the DMA code from from the videnc1_copy.c in the path: ./codec_engine_2_25_05_16/examples/ti/xdais/dm/examples/videnc1_copy/videnc1_copy.c. At that point I added DMAN3 directives to my server.cfg file. I added to my server.cfg based on the ./codec_engine_2_25_05_16/examples/ti/sdo/ce/examples/servers/all_codecs/all.cfg and ./framework_components_2_25_02_06/examples/ti/sdo/fc/dman3/examples/fastcopy/dm6467_nobios/fastcopytest.cfg.

    I've attached my server.cfg below. I've also attached my DSP algorithm code that uses the ACPY3 library. I do not make any calls to DMAN3. I assume this gets taken care of in the CERuntime_init() call from the server main(). I've also tried two configurations, one with DMAN3.useExternalRM   = true and with DMAN3.useExternalRM   = false. The results are the same, NULL DMA handles.

    Any help is greatly appreciated.

    Thanks,

    Brent

    8780.server.txt

     

    4466.videnc1copy.txt

  •  

    Regarding the ACPY3_activate() call failing/hanging, can you please check whether: 

    (1) handle->protocol == &ACPY3_PROTOCOL,

    (2) handle->env != NULL

    I am wondering if the codec in use has requested the IDMA3 channel for use by ACPY3_PROTOCOL. Otherwise, there is not much else here that should cause a hang.

    Murat

  • When your algorithm implements IDMA3_Fxns, it needs to declare this in its <Module>.xdc file.  Just as it sets it's IALG_Fxns, it should set it's IDMA3_Fxns.  Here's the VIDENC1_COPY.xdc file as an example:

    http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/ce/latest_2_x/examples/ti/sdo/ce/examples/codecs/videnc1_copy/VIDENC1_COPY.xdc

    From the initial trace log, I see this line, note the highlighted red:

    [DSP] @0,141,253tk: [+0 T:0x8fa40c84 S:0x8fa4492c] ti.sdo.ce.alg.Algorithm - Algorithm_create>
    Enter(fxns=0x8fa40510, idma3Fxns=0x0, iresFxns=0x0, params=0x0, attrs=0x8fa44a78)

    This tells me your alg isn't declaring it has any IDMA3_Fxns, and therefore, CE/DMAN3 don't grant you any IDMA3_Fxns-requested resources.

    Chris

  • Yes, the asserts definitely seem to indicate that NULL IDMA3_Handles are being used to configure transfers. 

    In your server.cfg, I think you might have to set something like this to declare a dependency on ACPY3:-

    VIDENC1_COPY.alg.useDMA = true;

    If the above is set to true, DMAN3 should be called and initialized automatically by the framework.

    I also don't see any trace from DMAN3 in your trace output above. 

    Could you add the following to your .cfg file:-

     

    	xdc.useModule('ti.sdo.fc.global.Settings').profile = "debug_trace";

    And get rid of the other lines in your .cfg file, that set the profile to debug/trace etc. You should have only one of those lines anyway.
    If you have a codec that implements IDMA3_Fxns , and no other codec that use IRES_Fxns, then you don't need to configure RMAN or EDMA3 modules. 
    So set DMAN3.useExternalRM to false, and get rid of lines that configure ti.sdo.fc.rman and ti.sdo.fc.edma3 package. Let's clean up the configuration and chase only one issue :)

    Re-build and re-run with CE_DEBUG=3 and attach the entire trace. You can check to see if there's any trace that has something like:-
    [DSP] @0,330,938tk: [+2 T:0x8fa053a4 S:0x8fa0786c] ti.sdo.fc.dman3....

    Also if you see any build warnings, please share those as well.

     

  • Chris,

    Thank you for your input!  I added the following line to my .xdc file and I am much further along:

       override readonly config String idma3Fxns = "VIDENC1COPY_ADSYS_IDMA3";

    The DMAN3 library is now getting called and my handles are not NULL. The program actually performs the first frame DMA successfully and then hangs in the _process() call on the second frame. I haven't had much time to debug this yet but I included my new CE_DEBUG trace if you guys have any ideas.

    Any idea what might be hanging my second call to VIDENC1_process?  Should I start a new thread or continue this one?

    Thanks,

    Brent

     

    0640.ce_debug_8_1dma_and_hang.txt