Hello:
In the McBSP driver I noticed that the following call to PAL_osCacheInvalidate() causes the memory BEFORE receiveAddr to be corrupted by data that was previously stored in that memory!
if( ((Uint32)TrnsAddr %32 != NULL) || ((Uint32)RcvAddr % 32 != NULL) )
{
retVal = PSP_E_INVAL_PARAM;
break;
}
/* Move the data to physical memory and invalidate the cache line */
PAL_osCacheInvalidate(
(PAL_osCacheMemAddrSpace)NULL,
(Uint32)(((PSP_mcbspTransParam*)(ioHandle->pspRequest.addr))->receiveAddr),
(Uint32)(ioHandle->pspRequest.size)
);
That buffer was passed in, and is 32 byte aligned.
I also read this from the DSP/BIOS users guide for BCACHE_inv (Called by PALosCacheInvalidate).
"The blockPtr (start address of range to be invalidated) points to an address in non-cache memory that may be cached in L1P, L1D, L2, or not at all. If the blockPtr does not correspond to the start of a cache line, the start of that cache line is used."
So my question is this.: Am I seeing the problem with alignment to the start of the cache line? How do I align my buffer to the start of a cache line. Would this fix this? Is it sufficient to just align to the largest cache size (L2 = 128 bytes on the DM6437) Regards, --B
