Adam, Thanks for the quick response. I'm not quite sure what you are saying. I basically took the example sphenc_copy codec as a template and customized it to create my own speech enc codec. All the configurations (contents in .tcf and .cfg) pretty much stayed the same. My codec algorithm does not explicitly call any DMA functions so I'm not sure how I'm "accessing the output buffers both by the CPU and DMA". I added a lot of code and data to the codec so the only change I can see is the increase in memory usage of the DDR region (4MB code, stack, static data). How can I debug this issue to see if the DSP and DMA are accessing the output buffers as you suggested? Like you said, this seems like a caching problem. I guess I'll try to handle the cache coherency myself, which the Framework is supposed to do for me automatically.
Anyone, any thoughts. Regards, Andy ----- Original Message ---- From: Adam Dawidziuk <[EMAIL PROTECTED]> To: Andy Ngo <[EMAIL PROTECTED]> Cc: "davinci-linux-open-source @linux.davincidsp.com" <[email protected]> Sent: Wednesday, February 28, 2007 9:09:49 PM Subject: Re: Cache coherency issue? Andy, Don't get me wrong by personally I think you don't exactly follow DMA rules in your algorithm. It seems that for some reason you access the output buffers both by CPU and DMA. Thus some part of data are left in cache, and some are in external memory. GT_trace probably access all your data by CPU thus performing automatic write-back when cache runs out. Are you 100% sure your data is coherent upon returning from the process call, presumably all in external memory? Hope you figure out the way and share this with community. I would certainly want to see what's going on, sine I had strange cache coherency problems myself... Best, Andy Ngo wrote: > According to a previous post > (http://www.mail-archive.com/[email protected]/msg00960.html), > the XDAIS Framework is suppose to handle cache coherency automatically > (points 1-4 in the post above). Recently, I have > been adding more and more code and data to my DSP speech codec and I've > been getting weird problems with the data exchanged > between the ARM and the DSP. For example, I would always get the same > exact data on the output buffer from a call > to SPHENC_process. In attempt to debug the problem, I put a GT_trace > call in my DSP speech codec to print out the data > that was being returned from SPHENC_process so that I can compare it to > the data I saw being returned to on the ARM side. > Weird thing is that by putting GT_trace in the speech codec, the problem > went away (the return data is different each time). > As soon as I comment out the call to GT_trace, the problem came back > (ARM side sees same data being returned). > > Am I doing something wrong? Is there a cache cohency problem here? Why > does adding a simple GT_trace fix the problem and > my data looks correct? Instead of GT_trace, I tried putting some hard > delays in an attempt to affect timing but that wouldn't > work, only a call to GT_trace work. I've been on this for several days now. > > Please advise. Thanks in advance. > > Regards, > Andy > > > ------------------------------------------------------------------------ > > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- Adam Dawidziuk Sentivision
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
