Re: [OpenOCD-user] Cortex M7/ATSAME70, breakpoints and cache

[Matthias W. <mat...@we...>]

On Donnerstag, 22. Februar 2018 09:36:19 CET Thomas Doerfler wrote:
> Hi Matthias,
> 
> just a short note: It's the icache which bothers me, not the dcache...
> and therefore an i-cache invalidate would be sufficent.

Unfortunately not. The i-cache is on top of the d-cache, so to modify code you 
need to clean&invalidate the d-cache to the point-of-unification (which is RAM 
in our case), then modify the code, then invalidate the i-cache

Also, as Tomas pointed out, you need to clean the d-cache anyway at debug 
entry because otherwise the debugger will not have a coherent view on the 
memory.

> 
> wkr,
> Thomas.
> 
> Am 22.02.2018 um 09:10 schrieb Matthias Welwarsky:
> > I looked into the cortex-m7 trm and the ARMv7-M architecture reference
> > manual, looks like we need to add at least some level of cache support
> > also for the cortex_m target. The registers are fortunately all memory
> > mapped and so it's likely quite straight forward "copy" of the cortex_a
> > code, keeping in mind that we do memory accesses through the AHB
> > interface and not through the CPU core.
> > 
> > That means, when setting or removing a breakpoint we need to
> > 1 - flush the affected cacheline out of the dcache. since code is
> > read-only, we might even get away with a d-cache invalidate but I think
> > it's safer to just flush the line out.
> > 2 - set/remove the breakpoint
> > 3 - invalidate the instruction cache
> > 
> > We don't need to identify the cacheline size, but we may need to check if
> > we have caches enabled or not. All in all, maybe 20 lines of code.
> > 
> >> I will try the "hbreak" and the openOCD override today.
> >> 
> >> wrk,
> >> Thomas.
> >> 
> >> ----- Ursprüngliche Mail -----
> >> Von: "Matthias Welwarsky" <mat...@we...>
> >> An: ope...@li...
> >> CC: "Paul Fertser" <fer...@gm...>, "Thomas Dörfler"
> >> <tho...@em...> Gesendet: Mittwoch, 21. Februar 2018
> >> 22:49:04
> >> Betreff: Re: [OpenOCD-user] Cortex M7/ATSAME70, breakpoints and cache
> >> 
> >> On Mittwoch, 21. Februar 2018 19:53:43 CET Paul Fertser wrote:
> >>> On Wed, Feb 21, 2018 at 11:36:36AM +0100, Thomas Doerfler wrote:
> >>>> I came around a serious problem regarding openOCD 0.10.0, an ATSAME70
> >>>> (Cortex M7) board, gdb and breakpoints (incl. single-stepping).
> >>> 
> >>> As a temporary workaround, you can use "hbreak" in gdb instead of
> >>> regular "break", that will make it use hardware breakpoints which do
> >>> not modify RAM.
> >>> 
> >>> There's also an openocd command that overrides default GDB behaviour
> >>> so that you can force any breakpoint set by GDB to be a hardware one.
> >>> 
> >>> HTH
> >> 
> >> I wonder why gdb doesn't use the single-stepping support that is
> >> undoubtedly implemented in the cortex_m target.
> >> 
> >> BR,
> >> Matthias