Tuesday, March 20th 2018, 1:26am UTC+1

You are not logged in.

  • Login
  • Register


Dear visitor, welcome to SEGGER Forum. If this is your first visit here, please read the Help. It explains how this page works. You must be registered before you can use all the page's features. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

Message information
Automatically converts internet addresses into links by adding [url] and [/url] around them.
Smiley code in your message such as :) is automatically displayed as image.
You can use BBCode to format your message, if this option is enabled.
Security measure

Please enter the letters that are shown in the picture below (without spaces, and upper or lower case can be used).

The last 4 posts

Thursday, March 15th 2018, 4:54pm

by jmcclintock

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:

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

For hardware breakpoint attempt:

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?

Thursday, March 15th 2018, 10:53am

by SEGGER - Nino


Thank you for your inquiry.
Such an issue is not known to us.
Which target device are you trying to program exactly?
Here is an overview of iMX devices with native QSPI support: https://wiki.segger.com/IMX_Series_Devices
Are you using custom hardware or an eval board?

Best regards,

Tuesday, March 13th 2018, 9:06pm

by jmcclintock

Cannot access memory at ...

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:

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?

Monday, March 12th 2018, 11:05pm

by jmcclintock

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

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?