Did anyone successfully debug an iMX6 with DCache enabled using Lauterbach debugger

[ffm]

Hi,

I try to debug some application running on iMX6 using a Lauterbach Debugger. This all works quite well, as long as the DCache is disabled. When enabled I'm getting spurious hangs of the debugger with the error message 'bus error generated by CPU' which seams to come from the debugger accessing some memory locations with the access going through the DCache.

When the DCache is enabled by the running application, sometimes after a break I'm able to step some instructions before the debugger hangs, but sometimes it hangs immediately after break or even during execution.

I also did some tests maually enabling the DCache via debugger with no program loaded but the ROM-code executing and had the same behaviour. Only when I list the code bypassing any caches by adding the memory class NC ('Data.List NC:r(PC)') I can successfully step through the code after DCache is enabled.

But anyway that doesn't help because 1st I also want to see memory as being modified in cache and 2nd when reading the PageTable via 'MMU.List PageTable' I can't apply the NC memory class either and thus I definately get the debugger hang when DCache is enabled.

Has somebody faced the same problem already and maybe a solution?

Regards

[b36401]

You can get Lauterbach Debugger and its documentation from Software Development Tools -> Debuggers and Runtime Analysis tab on this page:

http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=i.MX6Q&nodeId=018rH3ZrDRB24A&fpsp=1&t...

Have a great day,

Victor

-----------------------------------------------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer button. Thank you!

-----------------------------------------------------------------------------------------------------------------------

[ffm]

Hello Victor,

nice hint, but unfortunately the link for the "TRACE32 PowerDebug II" is broken and the link for the "TRACE32 PowerDebug Module USB3.0" ends up on a shop site of Lauterbach.

Regards, Frank

[igorpadykov]

Hi Frank

had you enabled mmu, there are SDK lauterbach init scripts

and examples in ..core/src/mmu.c  i.MX 6Series Platform SDK

Best regards

igor

[ffm]

Hi Igor,

I didn't find any initialization scripts for Lauterbach in the SDK. I just found the menu and peripheral description files. Anyway I use an adapted variant on the initialization scripts from this thread:

i.MX6 initialization and start-up scripts

Back to your question, the code that initially did the mmu+caches enable was the linux kernel decompressor of a zImage, which was loaded before by my bootloader, which didn't make use of either one. Thus, yes the code which enabled the DCache also enabled the MMU with some basic 1 to 1 mapping. Anyway I didn't use the example code from the SDK, as the code which enabled MMU+caches was not my code.

Investigating the problem with my recent tests I didn't load any code either. I configured the respective IO-lines on by board, that the ROM-Bootloader waits for the 'Serial Download' Connection via USB. With the ROM-Code executing I connected to the processor with my Lauterbach and stopped execution with the break command. The list command shows that the processor stops somwhere arround 0x00000FB6. Watching at the MMU registers (especially SCTLR) Shows, that MMU, ICache and DCache are disabled. Watching the SCR Shows, that the processor is in secure state.

At this time I'm just modifying the DCache bit via Lauterbach to enable the DCache. Afterwards, when stepping, the first step in the list window hangs up the Lauterbach with 'Emulation debug port fail'.

If I repeat the same procedure using list NC:r(PC) instead of the plain list command, I can further step througn the code.

So for the recent tests the MMU was not enabled thus I would exclude a faulty MMU mapping. It seams that any reads initiated by the Lauterbach debugger going through the DCache hang up the debugger. Thus either the cache access by the Lauterbach might be faulty or a possible cache miss by the Lauterbach leads to the failure.

Regards, Frank

[igorpadykov]

Hi Frank

D cache can only work when MMU is enabled

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka13835.html

https://community.freescale.com/thread/315745

Best regards

igor

[ffm]

Hi Igor,

it might be true, that DCache is only working if MMU is enabled and it sounds quite reasonable as the memory region's attributes which include cacheability are assigned by the tranlation table entries. Anyway I could not find such an explicit statement in the ARMv7 Architecture Reference Manual nor in the Cortex-A9 Reference Manual nor in the Cortex-A Programmers Guide. The article mentioned by you applies to ARM9 thus it might not apply to ARMv7.

My naive expectation was, that without MMU enabled the memory has besides the identity mapping some default attributes which may mark the whole memory as non-cacheable but should not lead to a crash, when just the DCache is enabled (without MMU). Exactly that is written in the ARMv7 Architecture Reference Manual §B3.2.1, which says: When a stage 1 MMU is disabled, then for data access the stage 1 translation assigns the Strongly-Ordered memory type. An explicit note says: This means the access is Non-cacheable and an unexpected data cache hit behavoir is implementation defined.

So in that you are true, that DCache is not working without enabled MMU, as the whole memory is non-cacheable.

In my case there was a bug in the DCache invalidation routine which I was able to find by comparing the running code with the SDK code, thus pointing me to the SDK was very helpfull. So after fixing the bug I was able to switch on DCache without MMU enabled and the target didn't crash anymore by access by the debugger. So you can enable just the DCache, but it will not cache any data. Anyway, if invalidated improperly as in my case this may lead to crashes obviously due to unexpected cache hits mentioned earlier.

Thanks for your support.

Regards, Frank