MCUXpresso - Jlink issue

[CktDesigner]

I've been debugging with MCUXpresso (version v11.7.0) and using SDK version 2.13.0

I'm using the MIMXRT1060-EVKB board.

I have a Jlink (base) that works when running the "hello world" demo.

It also used to work with my application.

However, something changed and now I can debug using the "onboard" (IDE Linkserver) method (with the appropriate jumpers in place), but if (the jumpers are removed and) the Jlink is used, the session seems to breakpoint before even starting.

As I mentioned above, this used to work.  And if I attempt to run "hello world" using Jlink, it works as expected.    So my assumption is that the Jlink probe hardware is working and something changed in the application Project that is interfering with Jlink.

The attached image shows the state of the IDE when the problem occurs.   It appears that it breaks attempting to access 0xdeadbeee (which I suspect indicates some specific condition?)

I tried removing the ...Jlink_Debug.Launch file from the project directory so it would be regenerated, but it didn't help.

Any suggestions on what to check or how to debug this condition?

Thanks!

[jeffrey_whitlat]

By any chance are you configured to run the code from SDRAM?

[CktDesigner]

No, it is set up to link to memory...   To I/D TCM...

Further debugging shows:

1. I set up a breakpoint at ResetISR, then stepped through the assembly instructions there.

2. It disables interrupts and assigns the initial stack pointer, then executes  a few assembly instructions that maps the on-chip SRAM.

3. It fails when calling "SystemInit()" with the error message shown in the original post

I though perhaps this was due to mapping the on-chip memory, but this code works with the "on-board" debugger...      Unless Jlink uses some memory space that the "on-board" debugger doesn't depend on???

[CktDesigner · Accepted solution]

It appears that mapping the I/D TCM was causing the issue...  Jlink must use portions of the on-chip memory that are not used when debugging with the on-board debugger...

[Evanee]

i have same question

[CktDesigner]

In my case, I was using ITCM and DTCM and they needed to be "mapped" prior to Jlink loading the code/data for debugging.    (Waiting for ResetISR was too late!)

This was solved by modifying the Jlink script to have it set the register that maps the on-chip SRAM.

1) In MCUXpresso, select your project and right click.   Select the "Debug as" menu item, then select "Debug Configurations"

2) In the "Debug Configurations" pop-up window, select the "JLink Debugger" tab

3) Scroll down to the "Script" entry

   A) In my case, this pointed to the "evkbmimxrt1060_sdram_init.jlinkscript" file in the Workspace ".mcuxpressoide_packages_support/MIMXRT1062xxxxA_support/Script" directory

   B) I copied the "evkbmimxrt1060_sdram_init.jlinkscript" file to a new file named "evkbmimxrt1060_tcm_init.jlinkscript" and edited the value in the script function "RestoreFlexRAM()" that is written to the (base + 44) address.   This is the register that allocates the onchip SRAM blocks.   Set it as needed by your application to map each block to ITCM/DTCM/OCSRAM.

4) Then I pointed to this new file in the "Script" entry (from step 3).

Then JLink writes the CPU register that maps the on-chip SRAM before loading the image...

Hope this helps!

[Evanee]

ths alot ooo

Could you give a more detailed explanation in this paragraph?

edited the value in the script function "RestoreFlexRAM()" that is written to the (base + 44) address.   This is the register that allocates the onchip SRAM blocks.   Set it as needed by your application to map each block to ITCM/DTCM/OCSRAM.

[CktDesigner]

You asked:  Could you give a more detailed explanation in this paragraph?

This address (Address: 400A_C000h base + 44h offset = 400A_C044h) is the IOMUXC_GPR_GPR17 register (in the iMXRT1062).   Each 2-bit field in the register maps one of the 16 on-chip FlexRAM (SRAM) blocks (blocks 0 -> 15) to one of:    00: Not Used,  01: OCRAM,  10: DTCM,  11: ITCM

See App Note: AN12077       It shows the "default" value in this register (as a function of the chip type).   I assume you haven't blown any of the fuses, so the default value for the fuses for this register would be 0b0000.   For the 106x parts, this would allocate 128K to ITCM, 128K to DTCM, and the rest to OCRAM.

When the fuses are 0b0000, the GPR_GPR17 register is preset to 0x55affa55.

To get a different allocation, the GPR_GPR17 register has to be written (usually in ResetISR), but this only works if you boot from Flash or load from Flash to some other (non-SRAM) memory, like SDRAM.    In my case (and yours?),  I don't have Flash or SDRAM and boot from an SD card right into I/D TCM.   So the allocation register must be set prior to the image load when debugging.   This is done via the JLink script (assuming you are using Segger JLink).   When booting from SD card, this is done via the DCD part of the boot sequence.   (The DCD block can be generated via the Config Tools in the MCUXpresso IDE.)

[Evanee]

VERY HELPFUL!!!!!

MANY THANKS!!!!

I have been troubled by this problem for a long time, thanks again.