I have had success using Eclipse Oxygen with single-step debugging RAM applications on the iMX7 M4 core using the J-LINK. I have since re-linked our application to run from QSPI. The application runs properly if I flash the QSPI using UBOOT, and then use the 'bootaux' command.

I have not had any luck attaching the J-Link Base to the running target to single-step debug. I have tried many variations of the Eclipse options in the debug configuration ("Connect to running target", with and without the "Initial Reset and Halt", with and without "Set breakpoint at:" etc.). The closest I have got it to working is to un-check "Connect to running target", I do perform the "initial reset and halt - type 1, 1000Hz, and I only load the symbols (not the executable) and do NOT have any breakpoints initially set. When I do this, the application is halted (as expected), and I appear to be in the MQX idle loop (as expected), and I can run and pause without issue, but if I attempt to set any breakpoints the J-Link seems to get lost in an infinite loop of reading registers.

The application is linked to have all .text in QSPI #1 on the Sabre SD iMX7 board, and the .data is in TCMU, and is extended to TCML using the standard (not lightweight) MQX memory model. Stack is in OCRAM_S.

Is this a limitation of the 'base' J-LINK probe?

thanks,
Jeremy

Just an update to the original post. I have a temporary unlimited flash breakpoint license and still encounter the error. I looked at the "Debugger Console" and it specifically indicates the following:


Warning:
Cannot insert breakpoint 3.
Cannot access memory at address 0x60100efa

The address is in external QSPI flash. I am now wondering if the issue is a simple access violation? I have tried making sure write protection is off via UBOOT before launching the application but this has no effect. Maybe I need to modify my script which attaches the J-LINK to the target to possibly allow access to this memory range/peripheral?

Hi Nino,

I am doing development work on the NXP iMX7 Sabre SD evaluation board right now. I have further explored the issue and I believe I had a misunderstanding about the root issue. If I link our application for the iMX7 M4 RAM, I am able to debug as expected. I can set breakpoints and single step without issue. If I link the same application for QuadSPI flash, I can manually flash it using the 'sf' commands from UBOOT, and I can successfully launch and run it using the 'bootaux' command from UBOOT. I have not been able to attach to the running target and step-debug though. I misunderstood the use of 'flash breakpoints' originally, and misunderstood how JFLASH worked. I now realize that JFLASH requires a direct SPI connection to the part which I don't believe exists on the SABRE SD board. But in my scenario, flash breakpoints should not be necessary, and I would think there are sufficient HW breakpoints in the M4 available to at least get one breakpoint working. But if I attempt to set any breakpoint in the flash memory region (0x60100000 - 0x601FFFFF) I get an error. Depending on whether I specify the breakpoint as "regular" or specifically "hardware" in Eclipse, the warnings are:


For regular breakpoint attempt:

Warning:
Cannot insert breakpoint 3.
Cannot access memory at address 0x60100efa



For hardware breakpoint attempt:

Warning:
Cannot insert hardware breakpoint 1.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.

I have also tried setting the breakpoint from the JLINK control panel and also get an error not matter what type of breakpoint I try.

My application does not have the QuadSPI configuration block linked at the start, because I am not just taking the M4 out of reset and letting it execute, I am manually launching it using bootaux. I was thinking that maybe the QuadSPI configuration block might enable some bus access that is required? I have tried looking at the FreeRTOS QSPI example and the only difference I see is that they enable the RDC for QSPI over this memory range. I have tried doing this via 'monitor' commands at startup but don't see any difference in behavior.

It seems like there is a fundamental access issue with the QuadSPI memory region and the J-LINK in this case? Or an inability to utilize the M4's hardware breakpoints for this memory region?

Hi Nino,

thanks for the reply. I installed the beta software and here are my results:

1) without 'flash breakpoints' enabled, I get the same behavior has before
2) with 'flash breakpoints' enabled I get the following console output:


Setting breakpoint @ address 0x60100EFA, Size = 2, BPHandle = 0x0001
Starting target CPU...
Comparing flash [....................] Done.
Erasing flash [....................] Done.
Programming flash [ERROR: Failed to erase sectors 16 @ address 0x60100000 (erase error)
....................] Done.

So it is at least trying to re-flash the QuadSPI with the breakpoint information but seems to fail on the erase. I have tried using UBOOT to ensure the flash is not write protected and believe it to be accessible, before launching the application and attaching with the J-LINK.

Question: Why doesn't the J-LINK use hardware breakpoints in this scenario instead of relying on flash breakpoints?