topic i.MX6SoloX DDR debug problem with Segger JLink in i.MX Processors

i.MX6SoloX DDR debug problem with Segger JLink

davidjaouen — Fri, 25 Mar 2016 13:44:25 GMT

Hi,

I'm trying to debug an application located in DDR and running on the M4 core of the i.MX6SX.

I'm using a Segger JLink+ probe and a i.MX6SoloX Sabre SDB board.

The A9 core boots U-Boot from QSPI NOR, then I load the M4 application using tftpboot and start the application using bootaux command.

To debug, I start the JLink GDB server (see attached script) then I connect using Eclipse.

I'm able to debug (breakpoints, stepping...) when the code is located in internal RAM (OCRAM or TCM).

When the code is located in DDR, I can set a breakpoint and stop on it. But then I cannot do anything, the M4 program counter is stuck and I cannot do stepping, examine memory...

Did anyone already experienced this problem? Any idea to solve this?

Regards,

David

Original Attachment has been moved to: iMX6SoloX_Connect_CortexM4.JLinkScript.zip

Re: i.MX6SoloX DDR debug problem with Segger JLink

davidjaouen — Tue, 10 May 2016 09:47:43 GMT

Hi all,

I'm still stuck on this problem.

Does one experienced this?

Best regards,David

Re: i.MX6SoloX DDR debug problem with Segger JLink

jeremym — Mon, 10 Oct 2016 21:12:51 GMT

Hi David - I am experiencing the same issue, did you find any solution yet? On the Segger forum there is a similar thread where the proposed solution was to disable cache which is screwing up the Segger JLINK breakpoint setting. I tried this but was unsuccessful.

The general method for debugging that I am using is as follows:

1) start the Sabre SD board and stop UBOOT before Linux loads,

2) execute the following commands in UBOOT to set the initial stack pointer and reset vector and take the M4 out of reset (mw.l 0x7f8000 0x20008000; mw.l 0x7f8004 0x1fff9001 144; mw.w 0x7f9000 0xe7fe; dcache flush; bootaux 0x7F8000) - NOTE: there is no actual application in memory at this point.

3) attach to the Sabre SD board using JLINK via eclipse, which downloads the application and performs a halt on the M4.

4) steps 2&3 seem 'backwards' to me, but its the only way I can get the JLINK to properly connect and download. I have tried just enabling the M4 core and connecting but this fails - it seems that establishing the stack pointer and initial vector (even if there is no code there), keeps the M4 is a somewhat 'predicable' state until the JLINK attaches and puts real code in memory. Maybe there is a more elegant way to do this for debugging? All of the NXP examples I have seen presume that you load the binary from SD/Flash into the final memory location BEFORE starting the core, but this doesn't seem possible when using Eclipse to load the .elf file via JLINK.

The results I am seeing when attempting to debug different memories:

1) If I simply load my application (built for DDR & TCM) with the JLINK through Eclipse and let it run (no breakpoints) after the initial halt, it seems to execute as expected; I can see what looks like the correct behavior on the M4 UART output and interact with it.

2) Any any attempt to stop and debug my application (built for DDR & TCM) results in a lock up. I can set the initial breakpoint anywhere, and the debugger stops properly. But any attempt to single step or run thereafter fails. In the failing state, the JLINK continuously loops on the following actions per the console:

..Breakpoint reached @ address 0x800006F2

Reading all registers

Read 4 bytes @ address 0x800006F2 (Data = 0xF0004802)

Starting target CPU...

...Breakpoint reached @ address 0x800006F2

Reading all registers

Read 4 bytes @ address 0x800006F2 (Data = 0xF0004802)

Starting target CPU...

...Breakpoint reached @ address 0x800006F2

Reading all registers

Read 4 bytes @ address 0x800006F2 (Data = 0xF0004802)

Starting target CPU...

...Breakpoint reached @ address 0x800006F2

Reading all registers

...

3) If I attempt to disable the cache (0xE0082000, 0xE0082800) the program fails to execute at all; not sure why this is? On the Segger forum this was listed as a possible 'fix' for debugging the M4 in DDR - seems to make my situation worse if I attempt to disable caching from UBOOT prior to loading and executing the image.

4) The same application built for OCRAM and TCM works just fine.

Re: i.MX6SoloX DDR debug problem with Segger JLink

evgenyerlihman — Wed, 18 Jan 2017 21:18:05 GMT

Hey Jeremy,

Any breakthrough on this issue? I am facing the same thing....

Thanks,

Evgeny

Re: i.MX6SoloX DDR debug problem with Segger JLink

ronenbenayoun — Thu, 26 Jan 2017 11:53:45 GMT

Hi Evgeny,

Please take at the following link:

How to build and debug FreeRTOS applications for CortexM4 on MX6SX

I hope it helps,

Ronen

Re: i.MX6SoloX DDR debug problem with Segger JLink

evgenyerlihman — Thu, 26 Jan 2017 14:07:16 GMT

Hey Ronen,

Thank you for the great tutorial! Have you had a chance to experiment with the same flow but with DDR instead of TCM?

I was able to debug the M4 using OCRAM, but both OCRAM and TCM are not big enough for my application. I was thinking about the posibillity of placing just the code that i need to debug in the TCM/OCRAM, but it seems a bit complicated and time consuming....

Thanks,

Evgeny

Re: i.MX6SoloX DDR debug problem with Segger JLink

ronenbenayoun — Fri, 27 Jan 2017 02:32:36 GMT

Hi Evgeny,

The only way I have been able to place breakpoints and step through the code is by not enabling the cache.

In the file: system_MCIMX6X_M4.c, function SystemInit() I just commented out all the Cache setup code. Since caches are disabled on reset, they remain disabled.

behavior is inconsistent but I can single step and set breakpoints. Here is what the function looks like:

void SystemInit(void)
{
/* The Vector table base address is given by linker script. */
#if defined(__CC_ARM)
extern uint32_t Image$$VECTOR_ROM$$Base[];
#else
extern uint32_t __VECTOR_TABLE[];
#endif

/* Enable FPU */
#if ((1 == __FPU_PRESENT) && (1 == __FPU_USED))
SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); /* set CP10 and CP11 Full Access */
#endif

/* M4 core clock root configuration. */
#if 0 //RB
/* Initialize Cache */
/* Enable System Bus Cache */
/* set command to invalidate all ways and write GO bit
to initiate command */
LMEM_PSCCR = LMEM_PSCCR_INVW1_MASK | LMEM_PSCCR_INVW0_MASK;
LMEM_PSCCR |= LMEM_PSCCR_GO_MASK;
/* Wait until the command completes */
while (LMEM_PSCCR & LMEM_PSCCR_GO_MASK);
/* Enable system bus cache, enable write buffer */
LMEM_PSCCR = (LMEM_PSCCR_ENWRBUF_MASK | LMEM_PSCCR_ENCACHE_MASK);
__ISB();

/* Enable Code Bus Cache */
/* set command to invalidate all ways and write GO bit
to initiate command */
LMEM_PCCCR = LMEM_PCCCR_INVW1_MASK | LMEM_PCCCR_INVW0_MASK;
LMEM_PCCCR |= LMEM_PCCCR_GO_MASK;
/* Wait until the command completes */
while (LMEM_PCCCR & LMEM_PCCCR_GO_MASK);
/* Enable code bus cache, enable write buffer */
LMEM_PCCCR = (LMEM_PCCCR_ENWRBUF_MASK | LMEM_PCCCR_ENCACHE_MASK);
__ISB();
__DSB();
#endif //RB
/* Relocate vector table */
#if defined(__CC_ARM)
SCB->VTOR = (uint32_t)Image$$VECTOR_ROM$$Base + VECT_TAB_OFFSET;
#else
SCB->VTOR = (uint32_t)__VECTOR_TABLE + VECT_TAB_OFFSET;
#endif
}

Not sure if this helps,

Ronen

documented here: Debug FreeRTOS applications for MX6SX in SDRAM