[SOLVED] J-Link GDB Server hard faults during the initial connection on Linux

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

  • [SOLVED] J-Link GDB Server hard faults during the initial connection on Linux

    Setup: J-Link V6.72a on Ubuntu 18.04 for my STM32F302CC using J-Link Mini EDU.

    More often than not, my J-Link GDB server sends my MCU to hard fault handler during the first connection. The problem goes away if I send a reset command ("Received monitor command: reset) but that doesn't seem quite right to me. Did I not configure something correctly?
    /usr/bin/JLinkGDBServer -select USB -device STM32F302CC -endian little -if SWD -speed 4000 -ir -LocalhostOnly -vd -strict
    SEGGER J-Link GDB Server V6.72a Command Line Version

    JLinkARM.dll V6.72a (DLL compiled Apr 30 2020 17:28:12)

    Command line: -select USB -device STM32F302CC -endian little -if SWD -speed 4000 -ir -LocalhostOnly -vd -strict
    -----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: on
    Silent mode: off
    Single run mode: off
    Target connection timeout: 0 ms
    ------J-Link related settings------
    J-Link Host interface: USB
    J-Link script: none
    J-Link settings file: none
    ------Target related settings------
    Target device: STM32F302CC
    Target interface: SWD
    Target interface speed: 4000kHz
    Target endian: little

    Connecting to J-Link...
    J-Link is connected.
    Firmware: J-Link EDU Mini V1 compiled Apr 23 2020 16:51:07
    Hardware: V1.00
    S/N: 801010965
    Feature(s): FlashBP, GDB
    Checking target voltage...
    Target voltage: 3.30 V
    Listening on TCP/IP port 2331
    Connecting to target...
    Connected to target
    Waiting for GDB connection...Connected to 127.0.0.1
    Reading all registers
    Read 4 bytes @ address 0x00000000 (Data = 0x2000A000)
    WARNING: Failed to read memory @ address 0xFFFFFFFC
    Read 4 bytes @ address 0x00000000 (Data = 0x2000A000)
    WARNING: Failed to read memory @ address 0xFFFFFFFC
    Read 2 bytes @ address 0x00000000 (Data = 0xA000)
    WARNING: Failed to read memory @ address 0xFFFFFFFE
    WARNING: Failed to read memory @ address 0xFFFFFFFC
    Read 2 bytes @ address 0x00000000 (Data = 0xA000)
    WARNING: Failed to read memory @ address 0xFFFFFFFE
    WARNING: Failed to read memory @ address 0xFFFFFFFC
    Read 4 bytes @ address 0x00000000 (Data = 0x2000A000)
    WARNING: Failed to read memory @ address 0xFFFFFFFC
    Read 4 bytes @ address 0x00000000 (Data = 0x2000A000)
    WARNING: Failed to read memory @ address 0xFFFFFFFC
    Read 4 bytes @ address 0x00000000 (Data = 0x2000A000)
    Read 4 bytes @ address 0x00000000 (Data = 0x2000A000)
    Read 4 bytes @ address 0x00000000 (Data = 0x2000A000)
    Read 2 bytes @ address 0x00000000 (Data = 0xA000)
    Debugger connected to localhost:2331
    Starting target CPU...
    Debugger requested to halt target...
    ...Target halted (PC = 0x08002CCA)
    Reading all registers
    Read 4 bytes @ address 0x08002CCA (Data = 0xB480E7FE)
    Read 4 bytes @ address 0x08002CC6 (Data = 0xAF00B480)
    Read 4 bytes @ address 0x08002CCA (Data = 0xB480E7FE)
    Read 4 bytes @ address 0x08002CC6 (Data = 0xAF00B480)
    Read 2 bytes @ address 0x08002CCA (Data = 0xE7FE)
    Read 2 bytes @ address 0x08002CC8 (Data = 0xAF00)
    Read 2 bytes @ address 0x08002CC6 (Data = 0xB480)
    Read 2 bytes @ address 0x08002CCA (Data = 0xE7FE)
    Read 2 bytes @ address 0x08002CC8 (Data = 0xAF00)
    Read 2 bytes @ address 0x08002CC6 (Data = 0xB480)
    Read 4 bytes @ address 0x08002CCA (Data = 0xB480E7FE)
    Read 4 bytes @ address 0x08002CC6 (Data = 0xAF00B480)
    Read 4 bytes @ address 0x08002CCA (Data = 0xB480E7FE)
    Read 4 bytes @ address 0x08002CC6 (Data = 0xAF00B480)
    Read 4 bytes @ address 0x08002CCA (Data = 0xB480E7FE)
    Read 4 bytes @ address 0x08002CCA (Data = 0xB480E7FE)
    Read 4 bytes @ address 0x08002CCA (Data = 0xB480E7FE)
    Signal: SIGTRAP (Trace/breakpoint trap)
    WARNING: Failed to read memory @ address 0xFFFFFFFD
    WARNING: Failed to read memory @ address 0xFFFFFFF9
    WARNING: Failed to read memory @ address 0xFFFFFFFD
    WARNING: Failed to read memory @ address 0xFFFFFFF9
    WARNING: Failed to read memory @ address 0xFFFFFFFD
    WARNING: Failed to read memory @ address 0xFFFFFFFB
    WARNING: Failed to read memory @ address 0xFFFFFFF9
    WARNING: Failed to read memory @ address 0xFFFFFFFD
    WARNING: Failed to read memory @ address 0xFFFFFFFB
    WARNING: Failed to read memory @ address 0xFFFFFFF9
    WARNING: Failed to read memory @ address 0xFFFFFFFD
    WARNING: Failed to read memory @ address 0xFFFFFFF9
    WARNING: Failed to read memory @ address 0xFFFFFFFD
    WARNING: Failed to read memory @ address 0xFFFFFFF9
    WARNING: Failed to read memory @ address 0xFFFFFFFD
    WARNING: Failed to read memory @ address 0xFFFFFFFD
    Read 4 bytes @ address 0x20009FB4 (Data = 0x61000000)
    Reading 64 bytes @ address 0x20009F80
    Read 4 bytes @ address 0x08007470 (Data = 0xBF00BF00)
    Read 4 bytes @ address 0x0800746C (Data = 0xDF008F6F)
    Read 4 bytes @ address 0x08007470 (Data = 0xBF00BF00)
    Read 4 bytes @ address 0x0800746C (Data = 0xDF008F6F)
    Read 2 bytes @ address 0x08007470 (Data = 0xBF00)
    Read 2 bytes @ address 0x0800746E (Data = 0xDF00)
    Read 2 bytes @ address 0x0800746C (Data = 0x8F6F)
    Read 2 bytes @ address 0x08007470 (Data = 0xBF00)
    Read 2 bytes @ address 0x0800746E (Data = 0xDF00)
    Read 2 bytes @ address 0x0800746C (Data = 0x8F6F)
    Read 4 bytes @ address 0x08007470 (Data = 0xBF00BF00)
    Read 4 bytes @ address 0x0800746C (Data = 0xDF008F6F)
    Read 4 bytes @ address 0x08007470 (Data = 0xBF00BF00)
    Read 4 bytes @ address 0x0800746C (Data = 0xDF008F6F)
    Read 4 bytes @ address 0x08007470 (Data = 0xBF00BF00)
    Read 4 bytes @ address 0x08007470 (Data = 0xBF00BF00)
    Read 4 bytes @ address 0x08007470 (Data = 0xBF00BF00)
    Read 4 bytes @ address 0x0800755E (Data = 0xFF45F7FF)
    Read 4 bytes @ address 0x0800755A (Data = 0xFF7DF7FF)
    Read 4 bytes @ address 0x0800755E (Data = 0xFF45F7FF)
    Read 4 bytes @ address 0x0800755A (Data = 0xFF7DF7FF)
    Read 2 bytes @ address 0x0800755E (Data = 0xF7FF)
    Read 2 bytes @ address 0x0800755C (Data = 0xFF7D)
    Read 2 bytes @ address 0x0800755A (Data = 0xF7FF)
    Read 2 bytes @ address 0x0800755E (Data = 0xF7FF)
    Read 2 bytes @ address 0x0800755C (Data = 0xFF7D)
    Read 2 bytes @ address 0x0800755A (Data = 0xF7FF)
    Read 4 bytes @ address 0x0800755E (Data = 0xFF45F7FF)
    Read 4 bytes @ address 0x0800755A (Data = 0xFF7DF7FF)
    Read 4 bytes @ address 0x0800755E (Data = 0xFF45F7FF)
    Read 4 bytes @ address 0x0800755A (Data = 0xFF7DF7FF)
    Read 4 bytes @ address 0x0800755E (Data = 0xFF45F7FF)
    Read 4 bytes @ address 0x0800755E (Data = 0xFF45F7FF)
    Read 4 bytes @ address 0x0800755E (Data = 0xFF45F7FF)
    Reading 64 bytes @ address 0xFFFFFFC0
    WARNING: Failed to read memory @ address 0xFFFFFFC0
    WARNING: Failed to read memory @ address 0xFFFFFFFC
    Reading 64 bytes @ address 0xFFFFFBC0
    WARNING: Failed to read memory @ address 0xFFFFFBC0
    WARNING: Failed to read memory @ address 0xFFFFFBFC
    And the backtrace looks like:
    #0 HardFault_Handler () at /home/thekenu/Consolidated-Firmware/boards/DIM/Src/stm32f3xx_it.c:93
    #1 <signal handler called>
    #2 0x08007470 in prvPortStartFirstTask () at /home/thekenu/Consolidated-Firmware/boards/DIM/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM4F/port.c:294
    #3 0x0800755e in xPortStartScheduler () at /home/thekenu/Consolidated-Firmware/boards/DIM/Middlewares/Third_Party/FreeRTOS/Source/portable/GCC/ARM_CM4F/port.c:386
    Backtrace stopped: previous frame inner to this frame (corrupt stack?)

    I know the debugger and the MCU is fine because I can easily swap between OpenOCD and J-Link GDB. And OpenOCD always suceesd while J-Link GDB gives me the hard fault error.
  • Hi,
    Thank you for your inquiry.
    Such an issue is not known to us.

    1) Do you use custom hardware or an evaluation board? In the latter case which one?
    1.1) If custom hardware, do you experience the same problem on an evaluation board?
    2) Could you please send us a J-Link log file? How to enable:
    wiki.segger.com/J-Link_DLL#Enable_J-Link_Log_File
    3) Could you provide us with a sample project this issue is reproducible with?

    Best regards,
    Fabian
    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.
  • Hey Fabian, thanks for getting back to me.

    1) I am using custom hardware but I was able to reproduce it on a evaluation board. I switched to using a Nucleo Board (STM32F302R8).
    1.1) To keep the scope manageable. I will just use the Nucleo Board as a benchmark rather than my custom hardware.
    2) I've attached a log file. For your information, a rough description of what I did in CLion is:
    Step 1. Start the debugger with a breakpoint in main.c
    Step 2. Click on the "Pause" button in CLion. Turns out the program is stuck in HardFaultHandler.
    Step 3. Click on the "Reset" button in CLion. The program breaks at the breakpoint in main.c.
    Step 4. Click on the "Continue" button in CLion, let the program run for a bit, and then click on the "Pause" button in CLion. Observe that we are no longer stuck in HardFaultHandler
    3) Here is a bare minimum project I created with STM32CubeMX: github.com/thekenu/jlink_test (Please use the "Embedded GDB Server" configuration file in CLion 2020.1.1 to reproduce this bug).

    I also just read your signature and realized maybe I could use the support ticket system? If that works better for you I am happy to move this discussion there as well. In any case, thanks for the help!
    Files
    • myLog

      (347.2 kB, downloaded 224 times, last: )
  • Hi,
    I reviewed the command lines you are passing to the J-Link GDBServer again.
    You are passing "-ir", which basically initializes most registers to "0".
    This is also the reason why a reset prevents this HardFault, because after a reset, the registers are not initialized anymore.
    OpenOCD most likely does not have an "-ir" option and therefore this does not occur when using OpenOCD.

    Could you try again without passing "-ir" to the J-Link GDBServer?

    Best regards,
    Fabian
    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.
  • Hey Fabian, that seems to have resolved the issue (at least with the limited amount of testing I have done). Thanks a lot, and please let m know if I am misusing any other J-Link GDBSever options. Out of curiosity, when is it appropriate to use the "-ir" option?

    Side note: I was also hoping that this would make the problem I mentioned in Unwanted SIGTRAP when adding breakpoints on Linux go away, but unfortunately that problem persists.
  • Hi,
    Sorry for the delay in response.
    Good to hear that you are up and running again.

    "-ir" initializes the CPU registers.
    This is required when the CPU is in a unexpected state after reset and the GDB Client is not setting the registers itself.
    Most proper GDB IDEs however do that, and it is therefore not necessary in such a case.

    We will consider this thread as closed now.

    Best regards,
    Fabian
    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.