I'm trying to improve performance of M4 execution by enabling 32KB of cache on iMX7. The application runs out of OCRAM e.g. 0x900000-0x93FFFF memory, and can be improved very much, by enabling LMEM-PS and moving the code segments to OCRAM alias, e.g. 0x20200000-0x2023FFFF memory. (actually NXP-Freertos package uses OCRAM-alias by default).
Everything works great.
For instance: by having some task be done within 25µs without cache, will be done within 3,6µs with enabled cache.
The only issue, is that once LMEM cache is enabled, JTAG debugger is not responding anymore. No step, step-in, step-out function are working. This makes software development very hard.
With disabled LMEM-PS cache, everything works correct, even from OCRAM alias memory.
Is there a trick fixing the issue?
I'm using DS-5 5.26.2 and ULINKpro D hardware debugger.
thank you in advance,
From JLINK/Segger perspective LMEM is Freescale/NXP specific:
So they don't /didn't handle it requiring you to disable the LMEM. From memory, they indicated it was too much of a change for them to support it.
Perhaps it's changed for 2020.
You can take a look into the AN5317, Loading Code on Cortex-M4 from Linux for the i.MX 6SoloX and i.MX 7Dual/7Solo Application Processors http://www.nxp.com/assets/documents/data/en/application-notes/AN5317.pdf
thank you for the response.
Document you've provided, refers to different case.
in my issue is, I'm trying to use JTAG debugger with a software running out of OCRAM (128KB) memory, but by using LMEM (caching), to improve the performance. For this I'm using to useing alias memory which is 0x2020_0000.
Everything runs well, but I'm not able to do step-by-step debugging. The debugger is not doing the step. Always stays at the same program code address.
such an effect can be seen when the debugger has an issue with the breakpoints. The ARM has a certain number of hardware breakpoints which are used when debugging in non-volatile memory (ROM , Flash). When the memory area is known as RAM, then the debugger will use software breakpoints, by using the BKPT instruction. The original instruction at this point will be replaced by the BKPT instruction.
I assume that there is an issue for the debugger with this RAM memory, maybe it is protected by the MMU (read-only mode) or breakpoints get overwritten, something like that.
Maybe it's possible for a test to work with an enforced hardware breakpoint:
There is also a limitation for the Cortex-M4 with breakpoints above 0x8000 0000, don't know if this can apply here.
My case is with J-Link JTAG, but it's the same problem by the looks of it.
About the MMU read-only access: what I don't understand then, if cache is disabled, I would or should, get same result, but I don't: as soon as the cache is disabled the breakpoints on OCRAM work.
So do you still think it's to do with MMU protection?