Have you ever tried debugging a beefy IoT-enabled chip connected to the world via Wi-Fi, Bluetooth, Ethernet, or even a good old boring CAN bus? You stop at a breakpoint, look through the variable values, maybe set a few other breakpoints… And find out that the connection has been reset because the other end had a fixed 50-millisecond timeout, and it took you slightly longer to study 10 different variables. I have hit this pothole far too many times, so when designing the key features for VisualGDB 5.5, I decided to do something about it.
Interestingly, most modern ARM devices provide a mechanism for reading their memory in a non-intrusive way, observing variable values, RTOS state, and even executed code branches in real time and without any interference with whatever the CPU is doing, although most modern debugging environments tend to not make use of it. So I’ve set myself a challenge to overcome this limitation and make debugging of real-time connected systems easier, and in this post I will show you what we have managed to accomplish.