Re: [OpenOCD-user] Cortex-M7 cache versus debugging

[Tomas V. <to...@us...>]

The bad news is both hbreak handling and gdb_breakpoint_override command 
are broken on Cortex-M.
Looks like a soft bp is always used for RAM region.

The good news is that CSW bit 27 really enables debug access though dcache.

Tomas

On 22.02.2018 12:03, Matthias Welwarsky wrote:
> On Donnerstag, 22. Februar 2018 11:19:55 CET Tomas Vanek wrote:
>> On 22.02.2018 11:05, Matthias Welwarsky wrote:
>>> On Donnerstag, 22. Februar 2018 10:39:29 CET Tomas Vanek wrote:
>>>> On 22.02.2018 9:58, Matthias Welwarsky wrote:
>>>>> 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.
>>>> I'm not aware of any possible way to memory access through CPU - it
>>>> still Cortex-M only.
>>>> On the other hand
>>>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0489b/BABE
>>>> FHA>>
>>>> D.html reads:
>>>>     *
>>>>     
>>>>       The instruction cache is not accessible to a debugger. Therefore
>>>>       debugger accesses to cacheable, executable regions of memory might
>>>>       not be coherent with the instructions visible to the instruction
>>>>       side of the processor.
>>>>     
>>>>     *
>>>>     
>>>>       The data cache must be enabled by setting the CCR.DC to 1 to read
>>>>       and write data to the cache. If CCR.DC is set to 0 all debug
>>>>       requests to memory regions outside the TCM and peripheral address
>>>>       space will access only the external memory on AXIM even if the debug
>>>>       request is marked as cacheable on the AHBD interface.
>>>>
>>>> The second paragraph looks like if CCR.DC = 1 debug mem access goes
>>>> through dcache. But it's obviously not true based on experience with
>>>> real HW.
>>> That's how I read it, too, but: you need to make sure that the memory
>>> access is marked as "cacheable", which I'm not sure openocd supports yet.
>>> If it works, it means that we don't need to flush the cache on debug
>>> entry. That would be very nice!
>> Yes, looks like setting bit 27 (cacheable) in CSW would do the trick on
>> AMBA 3 AHB-Lite
>> The question is if we can do all access with "cacheable" or it'll break
>> something...
> A "dap hprot" command that you only use in target files for cortex-m7?
> Or a variant of the mem_ap_read/write commands that carry access protection
> info?
>   
>>> The section about instruction caches just means that we need to maintain
>>> coherency in software when we set software breakpoints.
>>>
>>>> Or am I missing something?
>>>>
>>>> Tomas
>
>
> ------------------------------------------------------------------------------
> 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
>