|
From: Tomas V. <to...@us...> - 2018-02-22 09:39:33
|
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/BABEFHAD.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. Or am I missing something? Tomas |