[SOLVED] DEBUGGING doesn't work in external RAM, but in internal RAM

Hi,

sorry for the delay in response.
I could reproduce this behavior.
I will try to provide you with an explanation / solution to this issue tomorrow.

Best regards,
Niklas

Hi,


I forwarded this issue to my collogues, but they are currently totally booked, probably until the end of this week.
Sorry

Best regards,
Niklas

Hi,

we had a small time window on Friday evening to look at this issue.
At first glance, it seems like a problem in the silicon(CPU still reads the Breakpoint instruction, presumably of a cache, while the J-Link DLL reads the original instruction from memory). Unfortunately, we had 4 engineers call in sick today, therefore further investigation(initially scheduled for today) has been delayed.

Best regards,
Niklas

Hi Niklas,

I work with pca on this subject.
Do you have any news on why it is not possible to debug software running in external RAM on the Cortex-M4?
It's becoming quite urgent.

Best regards,
David

Hello David,

the i.MX SoloX features a Freescale specific memory controller called LMEM that features two Freescale specific cache controllers. (Named Code cache controller and System cache controller)
The System cache controller caches all memory addresses > 0x20000000, therefore it also caches the external RAM.
The J-Link sets breakpoints in RAM via the Cortex-M specific AHB (background memory access). This enables the J-Link to set soft BPs w/o halting the core.
But this bypasses this cache. Consequently, this leads to erroneous behavior.
For example, in your case, the BP is cleared, but the CPU stills reads the cached breakpoint instruction, while the J-Link reads the restored original instruction .

Internal RAM and Flash are not affected by this issue since the Flash has its own cache controller and the internal RAM is not cached at all.

The simple solution would be to use Hardware breakpoints, but this is not possible, since Cortex-M4 specification allows hw. BPs only for the range of 0x0-0x20000000, hence the external RAM (0x81000000) cannot be used with hw BPS.

Long term solution from our side: We will implement a special handling that clears and disables the cache before a J-Link accesses a cachable memory address, and enables caching after the access.
Short term solution: You need to disable the System cache during debugging:
(e.g in J-Link Commander:)
w4 e0082000,0 (=> disable Code cache[0x0 - 0x20000000])
w4 e0082800,0 (=> disable System cache[0x20000000 - 0xFFFFFFFF])

Best regards,
Niklas

Hi Niklas,

Thanks for your answer. I have some remarks:

1- Are you sure registers are located at addresses 0xE0082000 and 0xE0082800?
Because the iMX6SX refrence manual indicates the LMEM controller registers are located at 0xE0002000 and 0xE0002800.

2- The LMEM controller is disabled at boot and is not enabled by U-Boot. So, I'm not sure it has
any effect. Did you try it on board? (I didn't have time to check on board, will have some time
on next Monday or Tuesday).

3- When do you plan to do a release of the JLink software and/or probe firmware?

Best regards,
David

Hi David,

Because the iMX6SX refrence manual indicates the LMEM controller registers are located at 0xE0002000 and 0xE0002800.

We also noticed that, but this seems to be a typo in the manual, since this addresses collides with Cortex-M private peripheral registers.
We compared the manual to other Freescale manuals and found 0xE0082000 and 0xE0082800.

Did you try it on board?

Yes, we did. If you cannot reproduce this, I can do it again and provide you with screenshots.

When do you plan to do a release of the JLink software and/or probe firmware?

There is no planned release date yet.

Best regards,
Niklas

Hi Niklas,

We deactivated the LMEM caches as you mentioned and now we are able to
debug in external RAM on the Cortex-M4.

Thanks for your support.

Best regards,
David

Hi David,


Good to hear that you are up and running.


Best regards,
Niklas