Debugging while BT is working

[Elena]

Hi

I know perfectly it is not possible to debug while the softdevice is enable and the Bluetooth is working. When I try to set up a breakpoint under these conditions, the CPU restarts after resuming execution: I get a vetor catch exception.

My question is: Why happens this? Is this a protection to avoid inverse engineering of softdevice code? Or it is due to any other mechanism?

I think it is interesting to know why this happens because in my system, I'm using FreeRTOS with the SD, and sometimes, I get a vector catch exception: I suspect the BLE task is introducing delays in the SD execution and it should need a higher priority. Maybe this could trigger a vector catch exception in a similar way that pausing execution with the debugger.

Thanks in advance

Elena

[RK]

You can't avoid or fix the problem. The bluetooth stack is a realtime process (and that has nothing to do with the RTOS, I mean it's a process with very strict timing requirements). As soon as you stop it with a breakpoint and start it again, it's missed hundreds of ticks during which it had things it needed to do, the internal checks inside the softdevice then fail and the device faults, errors or hardfaults. it's not a protection mechanism, it's not a reverse engineering prevention mechanism, it's a hard timing requirement which debugging breaks and the softdevice HAS to shut down.

If you're using the nrf52 chip, find the blog post on monitor mode debugging. With that you CAN debug whilst the stack is running because breakpoints don't actually stop the CPU. The fact you're seeing vector catches sounds like nrf52. They are just an auto breakpoint before a fault handler runs.