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

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

On Donnerstag, 22. Februar 2018 09:29:26 CET Tomas Vanek wrote:
> On 22.02.2018 9:10, Matthias Welwarsky wrote:
> > On Donnerstag, 22. Februar 2018 08:55:46 CET Thomas Dörfler wrote:
> >> Hi Matthias,
> >> 
> >> using the single-stepping support wouldn't solve the caching issue. Even
> >> if
> >> you use single-stepping support will once again execute the breakpoint
> >> instruction, which is still in i-cache, AFAIK...
> > 
> > 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.
> 
> Please be aware that there is another Cortex-M7 cache issue besides
> broken RAM breakpoints.
> As memory is accessed through AHB, a debugger needs to flush whole data
> cache at debug mode enter
> to see actual value of memory variables/stack. And similarly data cache
> invalidate is needed
> at resume to ensure CPU will use values changed by the debugger.

Yes, you're correct, didn't think of that. That will slow down debug entry and 
exit quite a bit :-( Does the debug unit allow memory access through the CPU?
That will need quite some code to be ported from armv7a.

> At the present state of Cortex-M7 support there is the only way to use
> debugger: keep data cache off.

> 
> Tomas
> 
> >> 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
> > 
> > --------------------------------------------------------------------------
> > ---- Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > OpenOCD-user mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/openocd-user