Which part? The cache theory seems a good bet but the STM32F767 was recently found to have a bug in the EMAC. We switched to an F746. On Fri, Nov 25, 2016 at 2:35 PM Robin Iddon <[email protected]> wrote:
> 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 > > 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
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
