Hi Brian,
Does the codec uses DMA to fill the buffer? If it does, make sure it adheres to the rules in XDAIS (e.g. the DMA and CPU cannot both read/write from the same external memory buffer). The standard is defined in this doc: http://focus.ti.com/dsp/docs/dspsupporttechdocsc.tsp?sectionId=3&tabId=4 09&familyId=1300&abstractName=spru352g One way to ensure it is a cache-related problem is to see if the problem disappears when you turn off the cache for the memory region managed by CMEM using the MAR registers on the DSP. You can do so by modifying the DSP/BIOS .tcf file of the server, e.g.: bios.GBL.C64PLUSMAR0to31 = 0x0; // Assuming this is the MAR register corresponding to the CMEM region Another suggestion is to download the latest codec engine 1.20, which includes the stubs and skeletons for the VISA classes. They all use XDM_BufDescs, so e.g. viddec_stubs.c and viddec_skel.c could be a better reference for what you are doing. There wasn't any change between the s&s in 1.10 and 1.20 except for the extra invalidation of output buffers both before and after processing in the skeleton, which you are already doing. Using the CCS debugger to step through your code could also help, to see at what point the buffer gets corrupted. There is a wiki topic here that tells you how to connect to the DSP: http://wiki.davincidsp.com/index.php?title=Debugging_the_DSP_side_of_a_C E_application_on_DaVinci_using_CCS. The procedure in section 1.1 should be sufficient for you to be able to set breakpoints in your code. Best regards, Vincent ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian McFee Sent: Thursday, October 18, 2007 2:57 PM To: [email protected] Subject: codec engine, cache coherency problem I'm developing a codec based on the "scale" example provided in the codec engine package, and I'm running into some cache coherency problems: I occasionally get stale results from the codec. To test this, all of my output buffers are zeroed out in the application, and then set to non-zero constants in the codec/algorithm. The output buffers are usually correct (non-zero) upon return from the codec, but occasionally I see stale results (zeroes in all buffers), or a mixture of the two (some zero, some non-zero). I've modified the scale example to use XDM_BufDescs for the input and output buffers (one large input buffer and 3 relatively small output buffers). In the stubs part of the extension, I've added code to step through the BufDesc, doing the virtual-to-physical address translation for each buffer pointer and the bufSizes arrays. Each input and output buffer is allocated by contigAlloc, as well as the bufSizes arrays for the BufDescs. Similarly, the skeleton has been modified to invalidate caches following the same pattern as the scale example, but now extended to iterate over all buffers in the BufDesc. That is, first invalidate each input and output buffer, then process, then writeback-invalidate the output buffers. Just to make sure I'm not crazy, I also tried hard-coding the buffer lengths into the invalidate calls, but it doesn't seem to help. Could there be something screwy happening in the writeback-invalidate? I'm compiling with -O2, could this be affecting the cache-invalidate operations? For the sake of completeness, here are the library versions I'm using: dvevm 1.20 cmem 1.02 codec engine 1.10.01 codec servers 1.23 dsplink 1.30.08.02 xdais 5.10 xdc 2.94 I realize that these are not the most recent versions, but I haven't found anything (yet) in the release notes for later versions describing this sort of problem. Any help would be greatly appreciated. -- Brian
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
