E2 Server GDB crashing regularly at breakpoint

As mentioned in the title, since a short time the debugger is crashing reproducibly upon hitting a breakpoint. It does not happen at all breakpoints though. I have already tried to update the JLinkARM.dll file with the newest one from Segger. The call stack is displayed before the crash occurs (sometimes only empty entries for each stack frame).

I'm using e2 Studio 6.2.0, GCC ARM Embedded 6.2.1.20161205. Debugger is set to use SWD on a custom board with S5D5.

Any idea what to do about this?

Below you can find the call stack of the crash:

> msvcr100.dll!735fcc04()
[Unten angegebene Rahmen sind möglicherweise nicht korrekt und/oder fehlen, keine Symbole geladen für msvcr100.dll]
msvcr100.dll!735faf10()
msvcr100.dll!735fd6fd()
JLinkARM.dll!5158c57f()
JLinkARM.dll!515511e1()
JLinkARM.dll!5150b783()
JLinkARM.dll!514b6f52()
JLinkARM.dll!51563d16()
JLinkARM.dll!514b6913()
KernelBase.dll!756901e2()
msvcr100.dll!7358aaa1()
msvcr100.dll!73580949()
msvcr100.dll!7358260c()
KernelBase.dll!756901e2()
KernelBase.dll!7568d236()
KernelBase.dll!756901e2()
msvcp100.dll!67ad31d1()
msvcp100.dll!67acb487()
msvcr100.dll!7358016a()
msvcp100.dll!67ab30b8()
e2-server-gdb.exe!00b6d77e()
e2-server-gdb.exe!00b7d710()
e2-server-gdb.exe!00b7dee7()
e2-server-gdb.exe!00c6ce95()
e2-server-gdb.exe!00bbb660()
e2-server-gdb.exe!00bbf308()
e2-server-gdb.exe!00bbf72f()
e2-server-gdb.exe!00e4f94b()
e2-server-gdb.exe!00e50679()
e2-server-gdb.exe!00e5070e()
e2-server-gdb.exe!00bd41e7()
e2-server-gdb.exe!00bd41bb()
e2-server-gdb.exe!00bd4180()
e2-server-gdb.exe!00bd4142()
e2-server-gdb.exe!00e53c70()
msvcr100.dll!735cc556()
msvcr100.dll!735cc600()
kernel32.dll!76fe8744()
ntdll.dll!771058ed()
ntdll.dll!771058bd()

  • Hi Chris,

    Please try following:
    * Go to Run -> Debug Configurations and select your project on the left.
    * Go to Debugger tab.
    * add " --readnow" at the end of existing GDB command.

    Regards
  • In reply to Renesas Karol:

    Hi Karol,
    unfortunately this didn't change anything. I see the line at which it breaks and empty placeholders for the stack frames and then it crashes. My expressions view is empty and there are no memory monitors set.
  • In reply to ChrisS:

    I'm currently also having problems getting printf to work in any project (also new ones). It was working before with the usual steps --specs=rdimon.specs and following hal_entry.c code:

    /* HAL-only entry function */
    #include "hal_data.h"
    #include "stdio.h"

    extern void initialise_monitor_handles(void);

    void hal_entry(void)
    {
    initialise_monitor_handles();
    printf("Test\n");
    while(1){}
    /* TODO: add your own code here */
    }

    Do you think these problems might be related? Is it possible there's a hardware reason for this on our custom board? I think I'm going to reinstall all software (e2 Studio, GNU toolchain, SSP) and see if that helps.

    Edit: I just verified that printf works with a new project on S7G2DK, so it's either related to my debugger or our custom board it seems. I have the debug wires soldered on solder pads (TDI, TCK, TMS, GND, TDO, VTRef and one more GND). I have tried both JTAG and SWD pin configurations. Before when it was working it was configured with JTAG pin configurations but SWD in Debug configuration. I never had any issues with programming the device and the debugger is working at an earlier stage in the program and also in new projects.

  • In reply to ChrisS:

    Hello Chris,

    Problems with printf shouldn't be related to the other issue you were seeing. If there was any problem with JTAG pins you wouldn't even be able to make a connection. I've seen some printf reliability problems previously however they're difficult to reproduce (once you move project to a different machine it behaves differently). For that sole reason I recommend shifting to ITM printf or using UART.

    Coming back to the breakpoint problem - can you provide some information about trap placement? Does increasing interface (JTAG/SWD) speed help this problem at all? If the project was free-running (i.e. breakpoints disabled) how often would your breakpoint be hit?

    Regards
  • In reply to Renesas Karol:

    Hello Karol,

    in the meantime we received a new prototype of our board and I did some refactoring and this error doesn't occur anymore. The breakpoint wasn't hit too frequently. I'm using SWD with Auto setting for speed. The breakpoint was called from inside a threadX thread.
  • In reply to ChrisS:

    Back again to crashing debugger. I currently have a bug somewhere that leads to a crash in a memcpy call. The debugger stops and immediately crashes so I cannot see the callstack (only memcpy). In the meantime I have setup debug output through ITM which is working reliably (though it seems I need to call _write directly instead of printf). I'll try to debug this by hooking memcpy and printing memory locations/contents but I'm worried about the debugger. Below are my debug settings:

    Edit: Can this be related to having memory locations defined in the memory pane? I just removed them and it worked once, though it still crashes most of the time.

  • In reply to ChrisS:

    Hello Chris,

    Your settings look fine for an S5D5 device. Depending on the type of the debugger you're using, you can also hard-set SWD/JTAG speed up to 12MHz. Try disabling "RTOS Integration in Debug View" to see if this resolves your issue.

    Regards