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.

The dsp hung when calling VIDDEC_process() from arm side sometimes

Hi, all,

     Now i use DM6441 for video process, and meet one serious problem: the dsp hung when calling VIDDEC_process() from arm side sometimes. more detailed information and testing results are as follow:

     1) when the problem occured,   the problem always existed even if i reset the DM6441 SOC and reloaded *.x64P to run.

     2) if i comment some code in my codecs, the problem don't occur again. but the commented code is very simple and i can make sure that they are correct.

     3) when VIDDEC_process() is hung,  the call could return from dsp side after a very log time(e.g 4hours, 6hours, even more).

     i have several questions:

     A)  generally, what reason can hang the dsp except the codecs code meet infinite loop?

     B)  how to debug this problem?

     any help and sugguestion are appreciated.

 

  • Hello,

    You can debug the DSP by using the CE_DEBUG feature to obtain logs from both the ARM and DSP side of Codec Engine, see:

    http://processors.wiki.ti.com/index.php/CE_DEBUG

    If you have a JTAG you can also debug the DSP side using CCS, see:

    http://processors.wiki.ti.com/index.php/Debugging_the_DSP_side_of_a_CE_application_on_DaVinci_using_CCS

    It is difficult to hint at what your problem is, a rogue pointer in your codec or not enough stack are common issues. For more information about stack issues, see:

    http://processors.wiki.ti.com/index.php/Stack_issues

    Regards, Niclas

  • hello,Niclas

          I apologize in advance for this way to sak question.

           I run the videocopy demo in MCVIP(MCVIP can run on the board without any problem, capture and display),  I call videocopy demo to process the data,my program halt in ARM side ,do not go in the DSP side. the plantform is dm6467.

       the prime debug message is below:

       

    @10,855,945us: [+0 T:0x419c4b60 S:0x419c43f4] ti.sdo.ce.video.VIDENC - VIDENC_process> Enter (handle=0x6c998, inBufs=0x419c44a0, outBufs=0x419c4490, inArgs=0x419c447c, outArgs=0x419c44b0)
    @10,856,035us: [+5 T:0x419c4b60 S:0x419c437c] CV - VISA_allocMsg> Allocating message for messageId=0x0002e5c6
    @10,856,103us: [+0 T:0x419c4b60 S:0x419c434c] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x419c5000, size=706560)
    @10,856,167us: [+1 T:0x419c4b60 S:0x419c434c] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x419c5000, size=706560)
    @10,856,228us: [+1 T:0x419c4b60 S:0x419c434c] OM - Memory__getPhysicalAddress> returning physAddr=0x0
    @10,856,296us: [+1 T:0x419c4b60 S:0x419c434c] OM - Memory_getBufferPhysicalAddress> CMEM_getPhys(0x419c5000) = 0x87800000.
    @10,856,367us: [+1 T:0x419c4b60 S:0x419c42f4] OM - Memory__addContigBuf> Enter(virtAddr=0x419c5000, size=706560, physAddr=0x87800000)
    @10,856,433us: [+1 T:0x419c4b60 S:0x419c42f4] OM - Memory__addContigBuf> creating new contigBuf object
    @10,856,487us: [+0 T:0x419c4b60 S:0x419c42dc] OM - Memory_alloc> Enter(0x10)
    @10,856,549us: [+0 T:0x419c4b60 S:0x419c42dc] OM - Memory_alloc> return (0x6c738)
    @10,856,605us: [+1 T:0x419c4b60 S:0x419c42f4] OM - Memory__addContigBuf> returning: cb->phys=0x87800000, cb->size=706560, cb->virt=0x419c5000
    @10,856,667us: [+0 T:0x419c4b60 S:0x419c434c] OM - Memory_getBufferPhysicalAddress> return (0x87800000)
    @10,856,726us: [+0 T:0x419c4b60 S:0x419c434c] OM - Memory_getBufferPhysicalAddress> Enter(virtAddr=0x43f82000, size=706560)
    @10,856,786us: [+1 T:0x419c4b60 S:0x419c434c] OM - Memory__getPhysicalAddress> Enter(virtAddr=0x43f82000, size=706560)
    @10,856,845us: [+1 T:0x419c4b60 S:0x419c434c] OM - Memory__getPhysicalAddress> returning physAddr=0x0
    @10,856,910us: [+1 T:0x419c4b60 S:0x419c434c] OM - Memory_getBufferPhysicalAddress> CMEM_getPhys(0x43f82000) = 0x882c8000.
    @10,856,979us: [+1 T:0x419c4b60 S:0x419c42f4] OM - Memory__addContigBuf> Enter(virtAddr=0x43f82000, size=706560, physAddr=0x882c8000)
    @10,857,043us: [+1 T:0x419c4b60 S:0x419c42f4] OM - Memory__addContigBuf> creating new contigBuf object
    @10,857,099us: [+0 T:0x419c4b60 S:0x419c42dc] OM - Memory_alloc> Enter(0x10)
    @10,857,160us: [+0 T:0x419c4b60 S:0x419c42dc] OM - Memory_alloc> return (0x6cc48)
    @10,857,216us: [+1 T:0x419c4b60 S:0x419c42f4] OM - Memory__addContigBuf> returning: cb->phys=0x882c8000, cb->size=706560, cb->virt=0x43f82000
    @10,857,277us: [+0 T:0x419c4b60 S:0x419c434c] OM - Memory_getBufferPhysicalAddress> return (0x882c8000)
    @10,857,337us: [+0 T:0x419c4b60 S:0x419c438c] CV - VISA_call(visa=0x6c998, msg=0x41156880): messageId=0x0002e5c6, command=0x0
    @10,857,406us: [+0 T:0x419c4b60 S:0x419c435c] OC - Comm_put> Enter(queue=0x2, msg=0x41156880)
    @10,857,497us: [+0 T:0x419c4b60 S:0x419c435c] OC - Comm_put> return (0)
    @10,857,562us: [+0 T:0x419c4b60 S:0x419c4354] OC - Comm_get> Enter(queue=0x10001, msg=0x419c43fc

    halt in this,the full debug log in the appurtenance.1200.log7.txt

    in the normal condition,the next step is go in dsp process.but  program is halt.

    wish you help

  • When the Arm side hangs, can you connect a debugger to the DSP and see what it's doing?

    Best regards,

        Janet