On 02.08.2018 15:35, Antonio Borneo wrote:
On Wed, Aug 1, 2018 at 9:15 PM, Tomas Vanek via OpenOCD-devel
<openocd-devel@lists.sourceforge.net> wrote:
On 01.08.2018 19:13, Christopher Head wrote:
Hello!
I was wondering about how OpenOCD was meant to interoperate with CPU
caches. Right now, the Cortex M target has no cache management at all, which
means that, on devices whose debug buses connect directly to RAM, any memory
access through OpenOCD shows what’s in RAM, which may not be the same as
what’s in d-cache.

I had just always assumed that was intended behaviour until just now, when
I saw a patch posted regarding cleaning caches on Cortex-A, presumably so
that memory accesses would see what was most recently written by the CPU.

What is OpenOCD’s policy regarding cache coherence around debug accesses
to memory? If the policy is that they should be coherent, then I could
probably provide a patch making this happen for Cortex M at some point.

Hi Christopher,

If you mean Cortex-M7 DCache, please try

set CSW_HPROT3_CACHEABLE [expr 1 << 27]
samv.dap apcsw $CSW_HPROT3_CACHEABLE $CSW_HPROT3_CACHEABLE

and MEM-AP access goes through DCache.
Of course, some fancy ui wold be nice. Might be set by default in target.cfg
or so.

The only problem on Cortex-M7 is missing ICache flush after setting a RAM
breakpoint.
Not critical as you can use hw breakpoints only.

Tom
Hi Tomas,

have you already tested it?

Sure I did. Without setting CSW bit 27 and with cache enabled the debugging is almost impossible
(gdb doesn't read correct stack frames and RAM variables).


I'm checking ARM documents about Cortex-M7 but no mention about keeping
cache coherency with the bus accessed through the debugger.
Also Atmel/Microchip SAM-V documentation doesn't mention this important
feature.

I think such coherence mechanism should be too expensive for a MCU class
of products and, often, it's not implemented even on more high-end MPU
where the coherence mechanism is already in place for the SMP cores.

Actually this is not a coherence mechanism at all. Bit "cacheable" just instructs MEM-AP to use exactly the same way to access RAM as the only CPU uses. The debugger view is then
coherent with CPU view even if the DCache is dirty.

Some info is here:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0489b/BABEFHAD.html

Tom

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel

Reply via email to