See page 9 http://www.st.com/content/ccc/resource/technical/document/application_note/group0/08/dd/25/9c/4d/83/43/12/DM00272913/files/DM00272913.pdf/jcr:content/translations/en.DM00272913.pdf <http://www.st.com/content/ccc/resource/technical/document/application_note/group0/08/dd/25/9c/4d/83/43/12/DM00272913/files/DM00272913.pdf/jcr:content/translations/en.DM00272913.pdf>
This gives an example of a DMA induced coherency issue that arises when Dcache is on but not when it is off. > On 25 Nov 2016, at 21:03, Robin Iddon <[email protected]> wrote: > >> Surely the cache memory gets invalidated automatically regardless of the >> source of writing to it? > > > No, often that is not the case; if the CPU(s) write to the memory (through > the cache) then the cache is valid when another thread or whatever reads back > from it; if a DMA peripheral (pretty much any other bus master - look at the > bus matrix in the docs) writes to RAM then it will bypass the cache. > > You can in most CPUs have uncacheable memory regions such that you will > always get the data direct to/from RAM. In others you need to invalidate the > cache before reading the “volatile” memory. Depending on you performance > requirements there are trade offs between cache invalidation vs. reading > uncacheable memory region. > > You’ll need to look at the M7 manual (not sure which one you’re using) to see > how the data cache coherency is managed. > > The simplest solution is to map the memory reads/writes to descriptors and > packet buffers to go via the uncacheable memory space (often a case of ORing > in a high order address bit; not sure on M7). > >
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
