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 > > >
