This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Received a SIGTRAP: Trace/breakpoint trap

Hi

We use the nRF51822 with s110 active. As long the s100 isn't active, we can debug, set breakpoints, stop, continue like it should work.

When activating the s110 and communicate via ble interace, each time we run into a breakpoint and try to step foward/continue the following message pops up:

"Received a SIGTRAP: Trace/breakpoint trap"

The the application has to be restarted. So there isn't a way for useful debugging now!

We use gcc with visual gdb plugin and the segger JLink_V510g debugger. CXXFlags: -ggdb -ffunction-sections -fno-exceptions -fno-rtti -g3 -O0 -std=c++11 -fstdarg-opt

It seem's the debugger cannot handle interrupts of the softdevice...

Thanks for your help BR armin

Parents
  • Yes that's absolutely correct and discussed here quite often. If you break when the softdevice is running you get to look at the state of things at that point, but that's it, as soon as you try to step or re-start, the softdevice finds that it's missed many time critical events and aborts.

    You can set PRIMASK to block all interrupts before you try single stepping and that will let you step over a few instructions, but once you have stopped the softdevice and broken its timing, that's the end of that debug session.

    See the blog post from last week about Monitor Mode debugging with Segger for a different way to debug which helps somewhat.

Reply
  • Yes that's absolutely correct and discussed here quite often. If you break when the softdevice is running you get to look at the state of things at that point, but that's it, as soon as you try to step or re-start, the softdevice finds that it's missed many time critical events and aborts.

    You can set PRIMASK to block all interrupts before you try single stepping and that will let you step over a few instructions, but once you have stopped the softdevice and broken its timing, that's the end of that debug session.

    See the blog post from last week about Monitor Mode debugging with Segger for a different way to debug which helps somewhat.

Children
Related