[SOLVED] GDB Debugging of iMX6SoloX M4 Using Eclipse (NEON) & JLINK Base

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

  • [SOLVED] GDB Debugging of iMX6SoloX M4 Using Eclipse (NEON) & JLINK Base

    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 linked for the tightly coupled memory seems to write and be verified correctly according to the console output; we manually stop the A9 during boot and execute the recommended UBOOT commands to setup the vector table, enable the M4 core and take it out of reset.
    3) We are using the recommend JLINKSCRIPT for the M4 found on this forum
    3) The initial breakpoint does not seem to be set correctly, and any attempt to run/single-step or stop execution seems to always be 'stuck' at a single location. The program never seems to execute properly as we never see any expected debug output on the serial port. If we manually load the image into RAM via UBOOT and execute it works as expected - it also works with IAR workbench and DS-5, but not Eclipse.

    Some potential issues:
    1) what device should we be using? I have tried cortex-m4 and several imx6 variations, and I seem to get different results with the setting of the program counter depending on which I use. The register tab in the Eclipse debugger doesn't look correct to me regardless of what device I choose, so maybe I am missing something?
    2) I read a similar issue on the forum with cache being enabled, maybe this is the issue?
    3) I am not too sure if we need to modify/re-compile, or supply the GDB Client 'setup' (as Eclipse calls it) with some architecture specific information?

    I am wondering if anyone has successfully single-step debugged from Eclipse Neon on the M4?

    thanks,
    Jeremy

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

  • Hi Jeremy,

    We are using the recommend JLINKSCRIPT for the M4 found on this forum

    Do I understand you correctly, you got Eclipse to use the J-Link Script file and the connect to the device is successful?
    3) The initial breakpoint does not seem to be set correctly, and any attempt to run/single-step or stop execution seems to always be 'stuck' at a single location. The program never seems to execute properly as we never see any expected debug output on the serial port. If we manually load the image into RAM via UBOOT and execute it works as expected - it also works with IAR workbench and DS-5, but not Eclipse.

    As J-Link currently does not support flash programming of i.MX6 Solo X devices, I assume you download the target application to RAM?
    Which RAM do you use, internal or external?

    Best regards,
    Niklas
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    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 you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • 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 executable or pass it an argument?

    Some additional information, here is the console output - Eclipse seems to be 'stuck' at the Reset Handler (0x1fff8311) and it never changes - I don't currently have any breakpoint set there, but it always stops there:


    SEGGER J-Link GDB Server V5.12i Command Line Version

    JLinkARM.dll V5.12i (DLL compiled Jul 5 2016 19:01:50)

    -----GDB Server start settings-----
    GDBInit file: none
    GDB Server Listening port: 2331
    SWO raw output listening port: 2332
    Terminal I/O port: 2333
    Accept remote connection: localhost only
    Generate logfile: off
    Verify download: on
    Init regs on start: off
    Silent mode: off
    Single run mode: on
    Target connection timeout: 0 ms
    ------J-Link related settings------
    J-Link Host interface: USB
    J-Link script: C:\Program Files (x86)\SEGGER\JLink_V512i\iMX6SoloX_Connect_CortexM4.JLinkScript
    J-Link settings file: none
    ------Target related settings------
    Target device: mcimx6s4
    Target interface: JTAG
    Target interface speed: auto
    Target endian: little

    Connecting to J-Link...
    J-Link is connected.
    Firmware: J-Link V10 compiled Apr 28 2016 11:49:37
    Hardware: V10.10
    S/N: 50101423
    Feature(s): GDB
    Checking target voltage...
    Target voltage: 3.29 V
    Listening on TCP/IP port 2331
    Connecting to target...WARNING: At least one of the connected devices is not JTAG compliant (IEEE Std 1149.1, 7.1.1.d, IR-cells). (NumDevices = 4, NumBitsSet = 3)

    WARNING: At least one of the connected devices is not JTAG compliant (IEEE Std 1149.1, 7.1.1.d, IR-cells). (NumDevices = 4, NumBitsSet = 3)


    J-Link found 4 JTAG devices, Total IRLen = 17
    JTAG ID: 0x4BA00477 (Cortex-M4)
    Connected to target
    Waiting for GDB connection...Connected to 127.0.0.1
    Reading all registers
    Read 1 bytes @ address 0x1FFF8311 (Data = 0xB6)
    Read 1 bytes @ address 0x1FFF8311 (Data = 0xB6)
    Read 1 bytes @ address 0x1FFF8311 (Data = 0xB6)
    Read 1 bytes @ address 0x1FFF8311 (Data = 0xB6)
    Read 1 bytes @ address 0x1FFF8311 (Data = 0xB6)
    Read 1 bytes @ address 0x1FFF8311 (Data = 0xB6)
    Target interface speed set to 1000 kHz
    Select auto target interface speed (4000 kHz)
    Flash breakpoints disabled
    Read 1 bytes @ address 0x1FFF8311 (Data = 0xB6)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Reading 14 bytes @ address 0x1FFF8A10
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Downloading 576 bytes @ address 0x1FFF8000 - Verified OK
    Downloading 16096 bytes @ address 0x1FFF8240 - Verified OK
    Downloading 1832 bytes @ address 0x1FFFC120 - Verified OK
    Downloading 8 bytes @ address 0x1FFFC848 - Verified OK
    Downloading 4 bytes @ address 0x1FFFC850 - Verified OK
    Downloading 4 bytes @ address 0x1FFFC854 - Verified OK
    Downloading 116 bytes @ address 0x1FFFC858 - Verified OK
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Reading 14 bytes @ address 0x1FFF8A10
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8311 (Data = 0xB6)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Reading 14 bytes @ address 0x1FFF8A10
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Reading 14 bytes @ address 0x1FFF8A10
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    Read 1 bytes @ address 0x1FFF8A10 (Data = 0x80)
    R0 = 00000000, R1 = 00000020, R2 = 00000000, R3 = 00000000
    R4 = 00000000, R5 = 00000000, R6 = 00000000, R7 = 00000000
    R8 = 1FFF8311, R9 = 00000000, R10= 00000000, R11= 00000000
    R12= 00000000, R13= 20008000, MSP= 20008000, PSP= 00000000
    R14(LR) = 1FFF9009, R15(PC) = 1FFF9008
    XPSR 61000000, APSR 60000000, EPSR 01000000, IPSR 00000000
    CFBP 00002000, CONTROL 00, FAULTMASK 00, BASEPRI 2000, PRIMASK 00
    Reading all registers
    Read 1 bytes @ address 0x1FFF8311 (Data = 0xB6)

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

  • Hi Jeremy,

    I am not expert on this device.
    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

    This looks fine.

    I would suggest to give the following things a try:
    - Please update to the latest version of the J-Link software & documentation pack. Please make sure that Eclipse also uses the most recent version of the J-Link GDB server, which is also included in the package.
    -
    If we manually load the image into RAM via UBOOT and execute it works as expected

    What happens if you load the image via Eclipse + J-Link and then start the M4 via UBOOT?
    - Did you link the application also to 0x1FFF8000 when using IAR / DS-5? Or did you use the RAM located at 0x00900000? Does it work when using the RAM at 0x00900000?

    Are you using the SABRE eval board or custom hardware?

    Best regards,
    Niklas
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    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 you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • 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 -

    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 application in RAM/ROM.

    The console output continuously outputs the following when I try to single step after the code-load:


    Source Code

    1. Performing single step...
    2. ...Target halted (DBGRQ, PC = 0x1FFF9008)
    3. Reading all registers
    4. Performing single step...
    5. ...Target halted (DBGRQ, PC = 0x1FFF9008)
    6. Reading all registers
    7. Performing single step...
    8. ...Target halted (DBGRQ, PC = 0x1FFF9008)
    9. Debugger requested to halt target...


    2) The .elf file I am using was compiled with GNU/ARM/GCC toolchain - it's the FreeRTOS Hello world example from NXP. This works fine with IAR workbench and JLINK, but still no luck with Eclipse. The application is linked for TCM for the .text section, but does use DDR for the .data/stack/etc. Could this be an issue?
    3) Also, I am not sure of the correct settings for GDB server under Eclipse - here is what I am using: is "mcimx6s4" the correct device in this case?

    Source Code

    1. SEGGER J-Link GDB Server V6.10a Command Line Version
    2. JLinkARM.dll V6.10a (DLL compiled Sep 19 2016 20:07:49)
    3. -----GDB Server start settings-----
    4. GDBInit file: none
    5. GDB Server Listening port: 2331
    6. SWO raw output listening port: 2332
    7. Terminal I/O port: 2333
    8. Accept remote connection: localhost only
    9. Generate logfile: off
    10. Verify download: on
    11. Init regs on start: off
    12. Silent mode: off
    13. Single run mode: on
    14. Target connection timeout: 0 ms
    15. ------J-Link related settings------
    16. J-Link Host interface: USB
    17. J-Link script: C:\Program Files (x86)\SEGGER\JLink_V512i\iMX6SoloX_Connect_CortexM4.JLinkScript
    18. J-Link settings file: none
    19. ------Target related settings------
    20. Target device: mcimx6s4
    21. Target interface: JTAG
    22. Target interface speed: auto
    23. Target endian: little
    Display All


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

  • Problem Solved

    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/heap/stack in DDR:

    a) under first tab 'Main' locate the .elf file from your project - you can choose to enable auto-build or not, if you are just trying to debug the .elf without compiling/linking choose "Disable auto build" to prevent unnecessary errors on debug startup.
    b) under second tab 'Debugger'
    - 'Start the J-link GDB server locally' enabled
    - "Connect to running target" disabled
    - ${build_files}${build_files}${jlink_path}/${jlink_gdbserver} for "Executable"
    - mcimx6s4 for "Device name" - NOTE: if you are using the 'PACKS" to pickup devices automatically, the value pre-populated with the pack seems to be un-recognized by the GDB server and a pop-op will occur prompting you to choose an appropriate device (eventually times out and fails if you are not fast enough)
    - Little for "Endianes", USB for "Connection", JTAG for "Interface", Auto for "Initial speed" - all port values left at defaults
    - For "Other Options:" I kept the default values but added -scriptfile "C:\Program Files (x86)\SEGGER\JLink_V512i\iMX6SoloX_Connect_CortexM4.JLinkScript" - just point this to wherever your JLINKSCRIPT for the M4 is which can be found on this forum
    - The rest of the tab is essentially defaults - "Executable" under GDB Client is Setup is ${cross_prefix}gdb${cross_suffix} with default values of set mem inaccessible-by-default off for "Commands"
    - "Force thread list update on suspend" is disabled
    c) under third tab 'Startup'
    - Enable "Initial Reset and Halt." and set the "Type" to 1 - the default value of "Low Speed:" 1000kHz is fine. This was the setting which ultimately 'fixed' my original issue in the post. I have not found this documented anywhere and am not sure why it is needed, but it results in the debugger properly stopping after download, and all single stepping works correctly when it is setup this way.
    - "JTAG/SWD Speed" set to Auto
    - "Enable flash breakpoints", "Enable semihosting" set to disabled (unchecked)
    - "Load Symbols and Executable" left at default values - should point to your .elf file
    - "RAM application (reload after each reset/restart" - disabled - though enabled should work fine too
    - "Pre-run/Restart reset" - disabled
    - "Set program counter at (hex)" - disabled
    - "Set breakpoint at:" set to main (you can use whatever you want
    - "Continue" - disabled (this results in the debugger stopping at the initial reset vector initially) if you enable "Continue" it will automatically run to the first breakpoint - 'main' in this case.

    5) Debugger should be setup correctly now, reboot your board (we are using NXP Sabre SD board) - stop the A9 boot in UBOOT, and/or allow your application to setup the M4 as required and take it out of reset.
    a) If you stop execution in UBOOT - then you need to set initial stack pointer, configure PC value/vector table of M4, etc. as found in other posts on this forum and in NXP's AN5317.pdf - I used:
    mw.l 0x7f8000 0x20008000; mw.l 0x7f8004 0x1fff9001 144; mw.w 0x7f9000 0xe7fe; dcache flush; bootaux 0x7F8000
    6) The M4 core should now be running/out-of-reset - you can start your debug session. Depending on how you have setup your project - the initial code entry point may or may not be found by Eclipse, so make sure your source code is available to the project. Single stepping should work without issue.
  • Hi Jeremy,

    good to hear that you are up and running.
    Thanks for providing the detailed instructions.
    The mentioned script can also be found here: wiki.segger.com/I.MX6_SoloX_Support

    Best regards,
    Niklas
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    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 you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.