Search Results

Done (#6004024), thanks Nino.

Hello Nino - thank you again for the assistance, I think it is almost working, here is what I have found with both a temp J-FLASH and FLASH BP license. 1) If I connect to the iMX7D Sabre SD board with the M4 core as the target, I connect just fine but I am unable to set any flash breakpoints, it always fails. 2) If I connect with the A7_0 as the target, I AM able to set flash breakpoints, but these are never 'hit' Maybe it's the way in which we are running our two cores that is the issue? We hav…

Hi Nino, With a temp J-FLASH license I am able to program our QUAD-SPI part successfully. Do I need the Flash BP license to do ANY flash-breakpoints, or just UNLIMITED flash-breakpoints? Currently it will still not create even a single flash-breakpoint.

Thanks for the direction. I don't currently have a J-FLASH license, I will request a temp one. Do you have to have a J-FLASH license in order to set flash-breakpoints (I currently have the J-LINK base)?

Hello Nino - sorry to start another thread, the last thread was marked as closed before I had a chance to respond to your last inquiry. I am currently running J-LINK v6.34h family of tools. I am using Elipse as my IDE and have had success with RAM-based applications, but still no luck on QUAD SPI based applications running on the M4 core of the iMX7D. For my current debugging I am stopping the A-core in UBOOT and running the "sf probe" command with essentially sets up the QUAD-SPI interface allo…

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)…

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…

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. M…

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 th…

To anyone having similar issues debugging the M4 on the iMX6 soloX with the JLINK. Here are the basics: 1) Get Eclipse (I'm using NEON) 2) Install GNU ARM Eclipse plug-in (I'm at v3.1.1) 3) You can create a simple project with existing code if you just want to debug an ELF without setting up the entire toolchain. 4) Create a new debug configuration - here are the settings I used which seem to work for a RAM only image linked with the .text section in Tightly Coupled Memory (TCM) and the data/hea…

Hi Niklas - Here is an update: 1) I did update to latest JLINK SW - v6.10a - I still run into the same issues - namely that the debugger doesn't stop at the correct initial location and stepping of any kind fails and seems to be 'stuck' in a single location. I was unable to 'load' the application via Eclipse and execute from UBOOT because in order for JLINK to connect I need to take the M4 out of reset using the 'bootaux' command - which is the only way I currently know to 'launch' an applicatio…

Hi Niklas, 1) I will make sure we have the latest for the J-LINK installed. 2) I will try the Eclipse load - UBOOT execute and see how that goes. We are using the SABRE evaluation board. One question that comes up is: which 'device' string should we be using for this? I have tried 'cortex-m4' and am currently using 'mcimx6s4' - are either of these correct? Are there other options? thanks, Jeremy

Hi Niklas - 1) Yes we can connect and it appears that the code is getting correctly written to internal TCM M4 RAM. 2) The hello world program is linked for TCM only. I was talking with a colleague and am wondering if it may have something to do with the GDB client? Our 'prefix' is arm-none-eabi- and there is no suffix, so Eclipse should be executing arm-none-eabi-gdb.exe We are wondering how this client knows what ARM architecture it is communicating with? Do we need to recompile this executabl…

I have read through every thread I can find on the topic of iMX6SoloX M4 debugging and have not found a solution yet for Eclipse. We have successfully single-step debugged the M4 on a Sabre-SD Evaluation board using IAR and DS-5 with the JLINK, but with Eclipse Neon we have only been able to load the image into RAM but not execute nor single-step. 1) We have installed the GNU/ARM plug-in for the Segger JLINK, and this seems to be working OK 2) The JLINK connects and a simple hello world program …