arm cortex-m4 instruction "svc 0" causes (unexpected) SIGTRAP in gdb

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

  • arm cortex-m4 instruction "svc 0" causes (unexpected) SIGTRAP in gdb

    Hi all,

    I am using a SEGGER J-Link EDU probe with JLinkGDBServer and arm-none-eabi- toolchain on Linux to debug some software I currently develop on an STM32F427II processor.

    There is an SVCall done during initialization, using the instruction "svc 0". When running the code without debugger, it enteres the SVCall handler correctly and works as expected.

    When debugging with arm-none-eabi-gdb through JLinkGDBServer I receive "Program received signal SIGTRAP, Trace/breakpoint trap." and stepping does not step over the instruction, but lands at the same instruction again. My SVCall handler is never called.

    Is there some configuration that I am missing to disable this behaviour? - I am not interested in semihosting, I do not need this in my project. I would just like JLinkGDBServer to not stop on the SVC instruction.

    Thanks a lot in advance,
  • I am using latest 4.98:

    ls -l /opt/SEGGER/JLink
    drwxr-xr-x 3 root root 4096 Mar 31 16:31 Doc
    -rwxr-xr-x 1 root root 261920 Mar 26 18:43 JLinkExe
    -rwxr-xr-x 1 root root 329888 Mar 26 18:43 JLinkGDBServer
    -rwxr-xr-x 1 root root 41160 Mar 26 18:43 JLinkRTTClient
    -rwxr-xr-x 1 root root 194408 Mar 26 18:43 JLinkRemoteServer
    -rwxr-xr-x 1 root root 154872 Mar 26 18:43 JLinkSWOViewer
    drwxr-xr-x 4 root root 4096 Nov 25 19:25 Samples
    drwxr-xr-x 2 root root 4096 Mar 31 16:31 ThirdParty
    lrwxrwxrwx 1 root root 21 Mar 26 18:43 ->
  • Hi,

    Are you using GDB directly or via any IDE?
    Could you please post the command line you are using to start GDB Server and the executed GDB commands or a GDB Server log file?

    We just gave it a try and had no problems landing in the SVC Handler. When everything is set up correctly there should be no issues.
    For Cortex-M GDB Server will not set a vector catch on the SVC Handler, since for semihosting the bkpt instruction will be used.

  • Hi,

    I use gdb directly.

    Please find gdbserver.txt including command line and a sample gdb session log including my gdbinit and command lines attached.

    • gdbserver.txt

      (4.35 kB, downloaded 648 times, last: )
    • gdbsession.txt

      (2.14 kB, downloaded 628 times, last: )
  • Hi,

    Please find attached the sources we used to try to reproduce the problem.
    We used the same commands as seen in the log files, but the application does not halt on the SVC instruction
    and if halting manually with Ctrl-C we can see it is in main.

    Could you give this source a try?
    Does it cause a break on the SVC instruction, too?
    If not, could you check what is different to your application and modify it accordingly,
    so we would be able to reproduce it, too?


      (4.68 kB, downloaded 431 times, last: )
  • I could not reproduce the problem with the code I sent, but found a difference in registers right after starting gdb with my gdbinit file. With your provided code, I see LR is 0xffffffff and IPSR is 0. With my code LR was 0xfffffff9 and IPSR was 2. I use the clock security system on the stm32f427, this is connected to the NMI input of the core. Obviously there is an initial NMI at some point during startup when running under GDB, so the SVC trap comes in inside the NMI trap.

    I implemented a handler for NMI which resets the CSS interrupt. With this handler in place I see LR = 0xffffffff and IPSR = 0 with my code after initial gdb session start and I can step over or into the SVC trap correctly. This NMI is not issued without running under gdb, as my code starts properly without debugger. Thanks a lot for helping with this one.

    Now I am faced with the message:

    Program received signal SIGTRAP, Trace/breakpoint trap.
    0x00000000 in ?? ()

    after some time, my software just continues on running properly, but gdb is not connected anymore. The gdb server output at this time is as attached.

    There are three threads started at this point, and three interrupt handlers are called in between, the initial thread is running as idle task doing:

    while (1) {

    Best regards,
    • gdbserver.txt

      (5.56 kB, downloaded 647 times, last: )

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