JTAG debugger not working with enabled LMEM cache on M4 Core(iMX7)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

JTAG debugger not working with enabled LMEM cache on M4 Core(iMX7)

3,006 Views
wasp2k
Contributor I

Hi,

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,

Alexander.

Labels (2)
0 Kudos
7 Replies

2,236 Views
dry
Senior Contributor I

From JLINK/Segger perspective LMEM is Freescale/NXP specific:

https://forum.segger.com/index.php/Thread/2948-SOLVED-DEBUGGING-doesn-t-work-in-external-RAM-but-in-...


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.

0 Kudos

2,236 Views
dry
Senior Contributor I

Hello Alexander,

I got the same issue , but using Segger's J-Link.  

Have you worked out something about it? If you could share would be great ... 

0 Kudos

2,236 Views
niklasgranhage
Contributor I

Hello Alexander

I am facing the exact same problem, but I am using Eclipse+GDB and Segger J-Link.

Have you been able to solve the issue?

Best regards

/Niklas

0 Kudos

2,236 Views
jamesbone
NXP TechSupport
NXP TechSupport

Hello Alexander,

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 

Best Regards,

Jaime

0 Kudos

2,236 Views
wasp2k
Contributor I

Hello Jaime,

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.

Thank you,

Alexander May.

0 Kudos

2,236 Views
bernhardfink
NXP Employee
NXP Employee

Hello Alexander,

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:

Debug hardware device configuration settings  (Bypass memory protection when in debug)

ARM Information Center 

About breakpoints and watchpoints, commands "hbreak" and "set breakpoint", look for option "auto-hw"

ARM Information Center 

There is also a limitation for the Cortex-M4 with breakpoints above 0x8000 0000, don't know if this can apply here.

Regards,

Bernhard.

2,236 Views
dry
Senior Contributor I

Bernhard,

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?

Thank you

0 Kudos