Hello,
I am using a TMS320C6474 on a custom board. I have been trying to track down the cause of exceptions for many weeks now. I have seen that when an exception occurs, there is usually a corrupted program word in the L1P cache which either triggers an immediate exception, or which in turn causes a stack pointer corruption that eventually triggers an exception. I can see that the program memory in cache is corrupted by using the disassembly or memory view of CCSv4 - I can also see that the original memory in DDR2 RAM is not corrupt.
Hence I am either looking for some code writing to the L1P (or L2) cache and corrupting the copy of the op-codes, or there is corruption as I read from DDR2 memory into the caches.
A colleague suggested that it was worth setting a hardware watch point on the physical cache memory to trap any writes to it. The rationale being that there should not be any processor writes directly to any of the caches, and that cache fetches from main memory into the cache memory would not trigger a watch point as they are not normal processor writes. We are assuming that processor writes (which can be trapped by watch points) are to the physical memory address, and the cache controller would intercept them and re-direct them to the cached version - hence we believe that a write to cache watch point would not trigger if a write to memory is re-directed to the cache.
I have just setup the hardware watch point (data write into L1P cache, range: 0x00E0 0000 to 0x00E0 7FFF) and it is going off rather often.
- I have checked that no symbols have been linked to the cache memory.
- When it goes off, I cannot see any reason in the disassembly for the processor to have written to the L1P cache.
- It does not feel as though it is going off often enough for it to be cache fetches.
Can anyone throw any light onto what I should observe when I set a watch point on writes to the cache memories?
Paul
