What is the best and most stable debugging platform currently available for SAMD21 boards? I am currently using a Segger J-link Edu Mini with a WeMos M0+ board and Visual Studio/PlatformIO running on Linux. It is OK, but debugging is rather clunky. I have got to inject lengthy pauses between keypresses when stepping through code, unless I want the IDE to get really confused and lose the connection or hang. Not an ideal situation, but better than println. Ideally I'd prefer a solution for the Mega256, but I realise this will not happen soon, if at all.
Is there a better and more robust solution than what I currently have? Apart from liberal use of Serial.println(), what do other posters use? All I want to do is to inspect variable values and monitor program flow / logic by single stepping through my code. I don't need the debugger to respond to the status of I/O pins for instance, although that would be good to have.
The fact that any documentation on the WeMos is like rocking horse droppings doesn't help. Some people say it has an onboard debugger, some not. I suspect the latter, as it only has one USB port and I can't see the extra chip . I would happily invest in a genuine Arduino Zero or M0 Pro if it was a better or more stable debugging solution. If the truth be known, I wish I had done that in the first place as I am running into other issues with the board (i.e. it is not compatible with the standard Arduino LCD shields).
Should I bite the bullet, and if so, what board should I buy?
TBH, I have never used a debugger except the one time I used it in a production environment to help isolate hardware faults. In the many years I've been programming, I never had a debugger, and I never felt a need for one. If you follow best programming practices, you can almost always find the problems with either debug prints as you mentioned, or by close inspection and a structured walk through of the code.
Most of what I write is time sensitive anyways, so slowing it down by single stepping simply wouldn't work. Most peripheral interfaces can't be debugged that way, also because they require special timing.
In 99% of the cases when I was completely baffled, sleeping and looking at it with a cup of coffee in my hand the next morning, resulted in a fix within 5 minutes.
Debuggers can be a hoot! I was a Mac developer for years. We had some really nifty debugging tools. One showed your program logic patterns similar to the way a scope shows electronic wave patterns. You could run your program, do a capture, and it would generate something similar to a project chart of what the program did. When the different functions were called, how long they were active. What functions they were waiting on, different threads and how hardware was effecting timing as well. Cooler then heck.
I have got to inject lengthy pauses between keypresses when stepping through code
You probably need to be more selective about using breakpoints/watchpoints vs "stepping."
There is no reason to step through the vast majority of your code; only the sections that are mis-behaving.
I would happily invest in a genuine Arduino Zero or M0 Pro if it was a better or more stable debugging solution.
Those DO have a built-in debugger (but the the WeMos board, AFAICT), but I don't really see any reason to expect that the built-in debugger would give you anything more than you already have with the JLink. they both end up accessing the same core debugging primitives.
One thing that can be helpful is to put boring, known-working code into separate non-inlined functions, so that they can be "stepped over" instead of stepped through...
old_holborn:
All I want to do is to inspect variable values and monitor program flow / logic by single stepping through my code. I don't need the debugger to respond to the status of I/O pins for instance, although that would be good to have.
i often add conditional prints -- if (2 & debug) print (.... the debug flag allows you to select which debug prints you want. i have a function that monitors the serial interface for cmds that can change debug or execute sub-functions.
any SW debugging consumes time. prints at 9600 require 1 ms/character. you can capture values in a circular trace to minimize the impact on real-time processing and dump the buffer when it is complete.
one thing i assume is that debugging needs to be flexible. you add it when needed and probably remove a lot of it when done.
we would get log files from customers having problems with our femtoCell. we'd often have to tell customers to enable additional debug flags to help identify a problem.