The message handling on the DSP is performed by the same thread (a DSP/BIOS TSK) as the codec's "control()" thread. So, once the DSP gets the CONTROL command for the codec, it calls the codec's control() function, and upon returning from that control() function sends the "reply" command that gets picked up by the ARM app. If the control() function never returns, the "reply" message will never be received by the ARM. It is my assumption that the codec's control() function is not returning for whatever reason. You could try general things, such as increasing the DSP/BIOS TSK's stack size for the codec, but even though you don't have the TI codec's source code you could still put a BP on the codec's control() function and step it at the assembly level, or just see if it ever returns. If it doesn't return, it could be either a codec problem or a general DSP/BIOS system problem (such as not enough stack for the codec TSK).
Regards, - Rob ________________________________ From: Albert Burbea [mailto:[email protected]] Sent: Monday, January 04, 2010 11:55 PM To: Tivy, Robert Cc: davinci-linux-open-source Subject: Re: codec hangs Hi thanks for your help - the problem is that the JPEG codec is TI's and I do not have access to its source code. What could hang the message queue ? Thanks again Albert On Tue, Jan 5, 2010 at 3:47 AM, Tivy, Robert <[email protected]<mailto:[email protected]>> wrote: Nothing comes to mind from just your description. BTW, that "really strange" address (0xbeffc850) seems like a Linux user stack address. Since nothing jumps out from your top-down description, I would suggest a bottom-up investigation - debugging the DSP. Seems that the codec's "control()" code is sending the DSP into the weeds, at least with the parameters passed in. I would suggest putting a BP on the codec's "control()" function and stepping that function to see where the DSP goes bad. Regards, - Rob ________________________________ From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Albert Burbea Sent: Tuesday, December 29, 2009 11:22 AM To: davinci-linux-open-source Subject: codec hangs Hi everybody, I am using mv 4.01 with codec engine 2.01. I am integrating the TI JPEG encoder 1.1.13. At the beginning it did not work,it did not even open, until I modified the JPEGENC.xs to return the saram and daram scratch sizes. Before that, I modified also the ce/JPEGENC.xdc to use an IMGENC1 VISA interface instead of the IMGENC interface. I was able to open it and do an XDM_SETPARAMS control, but I did not try anything more. I restored the IMGENC interface in ce/JPEGENC.xdc, and compiled. Still worked. Then, I added a CMEM allocation for the output buffer, and... it hangs! Of course I removed the allocation and retried, but nope, I can only open it. Wen I execute the XDM_SETPARAMS, everything seems fine until the VISA_call for the XDM_SETPARAMS. The pointers it receives seem really strange to me, one of them if beffc850 or something like. It only enters the call, is able to queue the call, but then waits forever for the message queue to return, and everyting dies. What can be the problem? I verified several times the tcf file and the cmem settings and seem correct to me. Thanks in advance Albert -- Albert Burbea Harishonim 8 Ramat Gan 52502, Israel Tel/Fax + 972-3-7526016 Mobile: +972-52-3541842 -- Albert Burbea Harishonim 8 Ramat Gan 52502, Israel Tel/Fax + 972-3-7526016 Mobile: +972-52-3541842
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
