|
From: | Osborne, David |
Subject: | Re: [lwip-users] Why does enabling Debug fix this tcp_sndbuf() |
Date: | Thu, 25 Mar 2021 08:06:32 +0000 |
Damn you L1 cache! I would disable you permanently if you weren’t so damn fast. :) It appears cleaning the cache over the tx buffers address space has fixed the issue. My only concern is, it shouldn’t have. The tx buffers are set up as Normal Write through memory (T=0, C=1, B=0,
S=0). I have a sneaky suspicion cleaning the cache is simply providing the delay that the debug was (but hey a fix is a fix) @Alister Fisher I am using your
Ethernet patches. I was hoping to switch back to the mainstream by now, but I’m not confident ST has fixed all the issues yet. Thanks for your help everyone. Cheers David From: lwip-users <lwip-users-bounces+david.osborne=leicabiosystems.com@nongnu.org>
On Behalf Of Trampas Stern I had similar problem with an ATSAME70 which was an M7 core. Turns out that the ethernet driver from Microchip did not invalidate cache for the ethernet MAC driver. Hence it would work some of the time and not others, like when debugging
was on. Disabling the data cache on the processor would allow code to run with no errors. Microchip told me that none of their drivers were designed to work with cache on and to run ANY sample code or drivers required instruction and data cache to be turned off. Needless to say I rewrote their drivers. Also note the need for barrier instructions (__DSB(), __ISB()) these are often needed and vendor's drivers are missing them. For example barriers are often needed at end of interrupt handlers. Note even then some peripherals have caches
in the peripherals that can not be flushed with barrier instructions, for example Flash memory. I also ran into this as that right after writing to flash memory I would read back the wrong values due to flash peripheral caching. I had to create my own cache flush by reading large block of flash no near where I wrote, then returning
to where I wrote and reading again. The peripheral driver had a cache flush that did not work, so the reading different region was the only way to ensure the flash cache was flushed. The function below disables the cache in the core, part of core_cm7.h /** On Wed, Mar 24, 2021 at 3:11 PM
goldsimon@gmx.de <goldsimon@gmx.de> wrote:
|
[Prev in Thread] | Current Thread | [Next in Thread] |