UNIVERSAL_process

Flamingo

I'm debugging my IUNIVERSAL derived codec. In my GT trace output I see:

@4,412,673us: [+0 T:0x4001cf50] ti.sdo.ce.universal.UNIVERSAL - UNIVERSAL_process> Enter (handle=0x4f818, inBufs=0x0, outBufs=0x411fe000, inOutBufs=0x0, inArgs=0x411fc000, outArgs=0x411fd000)

My outBufs include the number of buffers:

@4,398,956us: [+1 T:0x4001cf50] brooks.z2_apps.vqm_results - GetVQMResults> 0x1

the virtual address of the buffer:

@4,399,110us: [+1 T:0x4001cf50] brooks.z2_apps.vqm_results - GetVQMResults> 0x411db000

and the size of the buffer:

@4,399,259us: [+1 T:0x4001cf50] brooks.z2_apps.vqm_results - GetVQMResults> 0xa4e0

All of these are outputs from the actual outBufs structure on the apps side, so I'm fairly certain that they are correct.

Later in the GT trace output, I find:

[DSP] @3,813,822tk: [+0 T:0xc2588a5c] ti.sdo.ce.universal.UNIVERSAL - UNIVERSAL_process> Enter (handle=0xc2588610, inBufs=0x0, outBufs=0x0, inOutBufs=0x0, inArgs=0xc5007efc, outArgs=0xc5007f04)

and the entry to my process function:

[DSP] @3,814,346tk: [+0 T:0xc2588a5c] brooks.vqm_results - VQM_RESULTS_process(0xc6000718, 0x0, 0xc5007f04, 0xc5007f04, 0xc6000718)

The numBufs, address, and size are wrong in my DSP side _process function:

numBufs (should be 1):

[DSP] @3,814,029tk: [+1 T:0xc2588a5c] brooks.vqm_results - VQM_RESULTS_process> 0x0

buffer (should be physical address?):

[DSP] @3,814,060tk: [+1 T:0xc2588a5c] brooks.vqm_results - VQM_RESULTS_process> 0x0

size of buffer (should be the same as app-size?):

[DSP] @3,814,092tk: [+1 T:0xc2588a5c] brooks.vqm_results - VQM_RESULTS_process> 0x8

It seems odd that the 3rd and 4th parameters (addresses) are the same. The associated trace call is

GT_5trace(curTrace, GT_ENTER, "VQM_RESULTS_process(0x%lx, 0x%lx, 0x%lx, 0x%lx, 0x%lx)\n",
h, inBufs, outBufs, inArgs, outArgs);

Can anyone advise me on why the outBufs and inArgs have the same value? Or any reason why the contents of the outBufs numBufs does not equal that on the app side? My control function seem sto work find, but it doesn't use these same structures. I check the inArgs and outArgs for size and the sizes of those is fine. Have I forgotten to set up something?

over 16 years ago

0 Chris Ring over 16 years ago

TI__Genius 17205 points

A quick peek at the code that 'marshals' the arguments on the ARM side shows that you may be hitting a [extremely ugly!] cut-n-paste bug. The maintenance of the outBufs in UNIVERSAL_process() when the alg is remote is flat out wrong when inBufs is NULL. Depending on your release, the line number may be different, but see approximately line 182 of ti/sdo/ce/universal/universal_stubs.c:

    /* Repeat the procedure for outBufs. */
    if (inBufs == NULL) {
        /* no outBufs */
        msg->cmd.process.outBufs.numBufs = 0;
    }
    else {
        ...
    }

Note the red, _errant_ check for (inBufs == NULL) when managing outBufs - it should be a check for (outBufs == NULL).

I can think of 2 workarounds:

1. Fix the red line above (inBufs -> outBufs) and rebuild this universal_stubs.c file - you can use the techniques here: http://tiexpressdsp.com/index.php/Overriding_stubs_and_skeletons

2. Provide a [unused] dummy XDM1_BufDesc for inBufs (maybe even with zero buffers?).

Lemme know what route you take and whether that works for you. I'll look at getting this fixed in a future CE release and adding it to the Known Issues page.

Chris

0 Flamingo over 16 years ago in reply to Chris Ring

Expert 2290 points

Good catch! I opted to provide inBufs with 0 buffers. The size, etc are now correct.

If I end up ahead of schedule (lol), I may try the other approach.

Thanks.

Processors

Processors forum

UNIVERSAL_process