0

I'm composing some GDB commands to make it behave like a "print()" function:

break Core/Src/main.c:243
commands
silent
printf "write addr: %d, val: %d\n", la, value
continue
end

That'd worked great until now. I've been bitten by this approach nearly every time I place such breakpoints into an interrupt handler. If the interrupt handler is called too frequently (such as a UART receive handler), above GDB composition causes delays, which leads loss of data, thus an unpredictable behavior.

If there is a way to determine the hit of a breakpoint during an interrupt, I would like to print a warning message to the rookie user (which is me, of course) that the breakpoint may lead to unpredictable behaviors.

Is there a way for the goal?

ceremcem
  • 1,386
  • 17
  • 35
  • 1
    Usually you know exactly which functions may get called in an interrupt. And it's kinda rare to have functions which can be called in an ISR and via normal execution. Is that your situation? – ErikR Jun 07 '21 at 08:40
  • @ErikR If I will put that kind of breakpoint [here](https://github.com/ceremcem/modbus_example/blob/724260c7999e6e0a799bb9ab942ff75038fa2cdb/Src/main.c#L74), which is called by [USART2_IRQHandler](https://github.com/ceremcem/modbus_example/blob/724260c7999e6e0a799bb9ab942ff75038fa2cdb/Src/stm32f4xx_it.c#L213), then above data loss situation will occur. – ceremcem Jun 07 '21 at 08:44
  • Sure, but just by the name of the function you know that it is called when an interrupt occurs. – ErikR Jun 07 '21 at 08:45
  • 1
    A function like USART2_IRQHandler is only going to get called as the result of an interrupt -- you're never going to call it directly. In general, a function will either be called as the result of an interrupt or you'll invoke it directly from your main thread. It's very rare to have functions which will be called in both ways. – ErikR Jun 07 '21 at 08:49
  • Ah, correct, I must know whether a function is called by an interrupt handler or not. But I'm placing such breakpoints by mistake, by forgetting that I shouldn't place them into that function. I just don't want to stay alerted all the time. The other way is statically parse the code and determine if a breakpoint will possibly called by an interrupt handler, but that's a long shot. – ceremcem Jun 07 '21 at 08:49
  • It's just part of the "bookkeeping" you have to keep track of mentally as an embedded developer. – ErikR Jun 07 '21 at 08:51
  • Obviously you can't use the serial port to debug the serial port interrupt handler, so you have to come up with other schemes to introspect the system. Here's a video which discusses one common approach: https://www.youtube.com/watch?v=VfpLyJvaBmc – ErikR Jun 07 '21 at 08:58
  • The other thing is that you shouldn't try to do a lot in an interrupt routine. For a UART ISR usually you just put the received byte in a buffer and your main thread processes the buffer every so often. So there's really no need to set a breakpoint in the UART's interrupt routine. – ErikR Jun 07 '21 at 09:13

0 Answers0