Hey,
the problem being discussed here is happening on an Atmel device
(ATSAME70). Is the bug on the STM32F767 device already in the errata
sheet? I'm currently using a 745 device, so I'm hopefully good. Apart
from the cache issues I ran into nothing special. I had a look at the
sheet don't quite understand why they're dragging erratas from prior
device generations into new ones...
Michael
Am 26.11.2016 um 19:30 schrieb Kenny Koller:
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]
<mailto:[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]
<mailto:[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] <mailto:[email protected]>
https://lists.nongnu.org/mailman/listinfo/lwip-users
_______________________________________________
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
