Hi Russ, And what if you use "handle SIGTRAP nostop noprint" instead?
Did you try it? BR, Alan On Fri, Nov 14, 2025 at 10:44 AM Russell Burgett <[email protected]> wrote: > Thanks Alan > have tried *handle SIGTRAP nostop noprint pass* > however GDB loses control and I cannot break > > GDB initialization script > > set confirm off > target extended-remote :3333 > handle SIGTRAP nostop noprint pass > handle SIGINT stop print nopass > set print pretty on > monitor reset halt > load nuttx > b ms8607_reset > b readEnv > info breakpoints > > resutls in this > "(gdb) c Continuing. Can't send signals to this remote system. SIGTRAP not > sent. Cannot execute this command while the target is running. Use the > "interrupt" command to stop the target and then try again. > > thanks for the quick reply > > Russ > > > On Thu, Nov 13, 2025 at 8:23 AM Alan C. Assis <[email protected]> wrote: > > > Hi Russ, > > Nice to hear from you here! > > > > Probably this issue is caused by semihost. > > > > You can confirm it running these commands in the GDB when the SIGTRAP > > happens to confirm: > > > > p/x $pc > > x/6i $pc-4 > > > > If you see "bkpt XX" then the main suspect is the semihost. > > > > You can disable SIGTRAP in GDB using this command: > > > > handle SIGTRAP nostop noprint pass > > > > More info: > > > > > https://stackoverflow.com/questions/6008140/how-to-debug-programs-using-signals > > > > BR, > > > > Alan > > > > > > On Thu, Nov 13, 2025 at 10:04 AM Russell Burgett > > <[email protected]> wrote: > > > > > Hi everyone, > > > > > > I’m currently debugging a NuttX-based project on an STM32F303CB > platform > > > with support for I2C, ADC, timers, USART, along with the MS8607 sensor > > > driver enabled. I am encountering an issue where the hardware > breakpoint > > > triggers a SIGTRAP signal every time it hits the context switch or a > > > semaphore wait. This leads to frequent and unintended halts in the > > > debugger, making it challenging to maintain a smooth debugging flow. > > > > > > I’ve tried various approaches to suppress these hardware breakpoints, > but > > > haven’t found a reliable method. I’m wondering if anyone has > encountered > > > similar challenges and has any suggestions or best practices for > handling > > > this? > > > > > > Any insights on configuring GDB or alternative debugging techniques > (like > > > SWO, RTT, or external tools) would be greatly appreciated. > > > > > > Thanks in advance! > > > > > > Russ Burgett > > > > > >
