Dear TI group,
I have searched for a strange bug of my DM642 application for quite a while. Since the effects of the cause of it can be quite severe (DM642 on a PCI card can crash the PC in which it is plugged in quite hard...), I wanted to tell you what I found out and add a question.
my app does:
1.) MEM_alloc(dataBlock
2.) EDMA Videoport->dataBlock
3.) (maybe) access parts of dataBlock in DSP code
4.) EDMA dataBlock->PCI->PC memory
5.) MEM_free
the basic problem seems to be:
MEM_alloc writes something behind the allocated memory block that seems to be important (did anyone of you know that?). If the size of the dataBlock is not modulo 128 (L2 cachelinesize) and you fill the memory through EDMA (for example from a Videoport) and access the memory, the FULL L2 cacheline gets updated. Result is that MEM_allocs special secret info gets overwritten!
After that anything can happen. Best case is that the next MEM_free/alloc/stat hang in some endless loop.
Worst case (happened in my case) is that some important info gets overwritten that is involved in the DSP->PCI->PC transfer. Leading to an acces to somewhere else than expected in the PCs memory. Best case: Linux freezes, Windows bluescreens.
Maybe some of you are searching for strange behaviour. Maybe such an allocation/cache thing can be the answer to some of the cases.
After padding the size of dataBlock to cacheLineSize the behaviour is much better. But still sometimes bruteForce testcases hang. Sometimes the PC crashes and when I access the DSP through JTAG I see that MEM_alloc/free/stat hangs in an endless loop.
What else do I have to care about when I allocate memory as described above?
best regards,
Thomas
