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

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] 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?

    thanks,
    Jeremy
  • 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:


    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?
  • Hello,

    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: wiki.segger.com/IMX_Series_Devices
    Are you using custom hardware or an eval board?

    Best regards,
    Nino
    Please read the forum rules before posting: Forum Rules

    Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support contact us per e-mail.
    The following contact form can be used for this: Contact Us

  • 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?

    The post was edited 1 time, last by jmcclintock ().

  • Hello,

    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?

    QSPI support has been added only recently with J-Link Software beta V6.31d. Should you be using an earlier software version QSPI Flash access will not work.
    The beta software can be downloaded here: segger.com/downloads/jlink/#J-…eAndDocumentationPackBeta

    Make sure your IDE is closed during installation so the J-Link DLL can be updated properly. Should the QSPI not work after installation you need to copy the /Devices folder and JLinkDevices.xml file from the J-Link install folder to the IDE install folder where the J-Link DLL is located.

    Best regards,
    Nino
    Please read the forum rules before posting: Forum Rules

    Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support contact us per e-mail.
    The following contact form can be used for this: Contact Us

  • 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?

    The post was edited 2 times, last by jmcclintock ().

  • Hello,

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

    The default is to use Flash BP to ensure that no unexpected errors show up for the user when using HW BP as they are very limited in use and many IDEs handle them incorrectly.
    Also HW BP are not supported by Cortex-M4 over address 0x1FFFFFFF so it would not work anyways.
    You can disable Flash BP e.g. in the J-Link control panel if wanted.

    How does uboot configure the QPSI Flash? Is it accessible in memory mapped mode so execute in place is available?
    Only then Flash BP will work in QSPI. Otherwise J-Link can't access the QSPI.
    Does using our QSPI Flashloader instead of uboot for programming the QSPI work instead?

    Best regards,
    Nino
    Please read the forum rules before posting: Forum Rules

    Keep in mind, this is not a support forum. Its main purpose is user to user interaction.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support contact us per e-mail.
    The following contact form can be used for this: Contact Us