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:
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.