Please do not reply to this email, use the link below. http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001837
--- Comment #7 from Mike Jones <mjo...@linear.com> --- I assume from Ilija's comments that DMA bypasses the cache, hence the need to invalidate it. When I disable CYGSEM_HAL_ENABLE_DCACHE_ON_STARTUP, I get a conflict saying startup mode must be WRITETHRU, which it is , but is also disabled (conflict comes from CYGPKG_HAL_FREESCALE_EDMA). Perhaps this is a bug. My purpose in disabling it to make it consistent with the 100Mhz device's behavior, and make sure there is no side effect from enabling a feature the device does not support. The conflict did not prevent my app from running. I assume the TCD limitation is because the eDMA logic in the device is connected tightly with the memory bus logic and can't route through the cache, similar to how DMA works directly on memory without the cache. I put breakpoints in the SPI dma setup to see where the buffers reside in memory and they reside in Cache Data RAM just above 0x60400000. I will attach a couple of screen shots with the location. I assume some code will need to be added to invalidate the cache if the code is not already present somewhere, move to another segment without cache, or require turning off caching. Perhaps someone knows if there is cache invalidation code already. For now, I am ok because there is no caching for my 100Mhz device. I believe that whatever is overwriting the device variable is not related to FXM based on what I learned here. There is also evidence that the stack is corrupt in other places because the debugger is not giving a complete stack trace. So I will take the discussion back to the MCC/SPI bug if I discover more. Thanks -- You are receiving this mail because: You are on the CC list for the bug.
