Unable to set breakpoints in iMX7 QSPI based M4 application with the J-Link Base

[jeremym]

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 application into QSPI using UBOOT, and then use the 'bootaux' command (NOTE: I do not have the QSPI configuration struct included in my application - it won't boot from QSPI without using the bootaux command from UBOOT).  But now, if I try to attach the debugger to the running target to debug it, I am unable to single-step (or set any breakpoints other than the initial 'halt') without getting the following error from the GDB server:

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

0x60100efa is 'main' in this case.  The debugger then just seems to go into the weeds.  My series of steps to reproduce this are:

1) stop the iMX7 Sabre SD board in UBOOT

2) launch the M4 QSPI application using 'bootaux 0x60100000' - the application is running correctly at this point

3) attempt to attach to running target using Eclipse - then I encounter the error above if I have any breakpoints set, or attempt to add a breakpoint after halting the processor.

The application is linked to have all .text in QSPI #1 (0x6010000 - 0x601FFFFF) 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.  I have the unlimited flash breakpoint license for the J-LINK, but I believe I may some QSPI bus access problem possibly?  Maybe because I am not first booting directly from QSPI (by having a properly formed QSPI config table linked first in my application)? 

Any insight would be greatly appreciated.

[igorpadykov]

Hi Jeremy

one can recheck application memory layout, for example M4 vector table

(may be used for debugging) should be in OCRAM_S as described in

sect.3. Reloading Code on the i.MX 7Dual/7Solo AN5317

Loading Code on Cortex-M4 from Linux for the i.MX 6SoloX and i.MX7Dual/7Solo Application Processors

https://www.nxp.com/docs/en/application-note/AN5317.pdf 

Some qspi examples can be found in FreeRTOS_BSP_1.0.1_iMX7D:

 Board Support Packages (3)
FreeRTOS_iMX7D_1.0.1_LINUX(REV 1.0.1)
https://www.nxp.com/products/microcontrollers-and-processors/arm-based-processors-and-mcus/i.mx-appl...

please check Getting Started with FreeRTOS BSP for i.MX7Dual.pdf  sect.7 Debugging Application

included in doc folder.

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

[jeremym]

Hi Igor - no luck with setting up the RDC for QuadSPI.  That is the only difference I see between the FreeRTOS QuadSPI example and what I am trying to do.  Is there anything which would prevent the iMX7 M4 debug core from accepting HW breakpoints when the address in question is in external QuadSPI flash?  That seems to be the root issue here.

[igorpadykov]

Hi Jeremy

had you checked that M4 vector table in OCRAM_S in compiled image.

One can try with other debuggers, to narrow down problem.

Issues with j-link can be posted on segger forum.

[SOLVED] Support of NXP's i.MX7 - J-Link/Flasher related - SEGGER Forum 

Best regards
igor

[jeremym]

I can try the M4 vector table in OCRAM_S, but I am failing to see how that is related to J-LINK debugging?  I am under the impression that the J-LINK should try and set HW breakpoints within the M4 core itself?  I have posted on Segger's site as well but am not getting any feedback currently.  The only debugging in QuadSPI for iMX7 M4 that I have found is all tied to IAR's toolchain.  I have to believe someone has successfully step-debugged and iMX7 M4 using J-LINK and Eclipse?  The M4 seems to be blocking the setting of the HW breakpoints for this region?

[igorpadykov]

>I can try the M4 vector table in OCRAM_S, but I am failing to see how that is related to J-LINK debugging?

in general debugger can use M4 vector table for own purposes

Best regards
igor

[jeremym]

Hi Igor - I relinked the application to use OCRAM_S for the vector table.  The application will run OK once launched from UBOOT, but when I try to attach the debugger I still get:

Warning:
Cannot insert breakpoint 2.
Cannot access memory at address 0x60100de6
Cannot insert breakpoint 1.
Cannot access memory at address 0x60102622

Command aborted.

Both addresses are in QUADSPI memory region.

[jeremym · Accepted solution]

Segger has indicated that this is likely an issue with J-LINK's support of QSPI memories and is working on a solution; a thread with this information can be found here:

Unable to set breakpoints in iMX7 QSPI based M4 application with the J-Link Base - J-Link/Flasher re... 

[jeremym]

Thanks for the reply Igor - since the application executes from QuadSPI OK, when I launch it from UBOOT using the 'bootaux' command, I believe the vector table is being correctly copied into RAM, though not OCRAM_S.  I am under the impression that the RAM vector table could reside anywhere, as long as its location is known?

I have noticed that when running my application in RAM only, the Segger J-LINK correctly identifies my breakpoints.  When running in flash, no break points are recognized.  If I use the JFLASH SPI application, it is unable to auto identify the external QuadSPI part on the Sabre SD board, even though it is listed as a supported device in the 'auto detect' list.  This makes me think the JTAG does not have access to the QuadSPI bus perhaps, so I am trying to figure out how to 'enable' the access?  Maybe if the application boots directly from QSPI there is some additional configuration which occurs to allow the JTAG access to the QuadSPI bus?  Or possibly its due to the fact that I am connecting to the M4 Core with the JTAG, and not the A Core?

I am looking into the FreeRTOS QSPI hello world example - I see that they modify the RDC for QSPI access - maybe this is the issue.  I will attempt it in my setup.