I have a sketch the hangs at a certain place in the code, depending on the outcome of a prior section of code. I've exhasuted all ideas using printf debugging to the Serial Monitor. I'm running on a Teensy 4.0 board, using the Teensyduino IDE.
I'm somewhat shocked that I can't find a way to single-step through my code, watch variables, etc. Looking for help on how to do some basic debugging. Thanks!!
Perhaps if you posted your code someone could suggest an approach. One technique that I have been using along with printing messages indicating the path being taken through the code and the value of significant variables is to add while loops at various points in the code that are controlled by Serial input to allow the code to continue.
This is painful and in no way replaces a proper debugger with the ability to set breakpoints, single step and examine or change the value of variables, but it is all I have
Note: If the sketch crashes and resets the processor, the characters in the output buffer will never get to Serial Monitor. Put Serial.flush(); after each debug message so the output completes before going on to code that might crash. That will get you better debug output and allow you to localize the problem.
That is because your C code is first converted to assembly, and then compiled into executable instructions for your particular processor. A programing language that uses an INTERPRETER can do what you suggest.
This is why it really helps to test as you go. It sounds like you're engaging in a bit of big-bang testing, which rarely goes well. You may find it helpful to remove (or comment out) sections of your code until you get to a point where you have something working and then start adding it back a bit at a time.
No, not everyone in industry.
The problem with a debug build as it is called is that it runs slower than the code normally would. It is not unknown for a debug build to work fine, only to fail when all that debug support is removed.
The clue here is real time. The solution to this is to use a logic analyser injected to the data bus and address bus and decode the actual code and turn back into assembly code. That will only work if these are exposed, which they tend not to be in a lot of small embedded systems.
Most of these sort of problems turn out to be with the operating system, which is why you should avoid them if possible.
Yes, I saw such a box at the Unisys plant in Plymouth, MI. I was writing communication software for a PC to communicate with their check reader/sorter and the communication was dying. An engineer used such a device to track the
Well you can let some users here take a look into your code to get new ideas how to debug it. If your code is not top secret and you did'nt signed a NDA (non disclosure agreement) post your code with this method:
You should post code by using code-tags
There is an automatic function for doing this in the Arduino-IDE
just three steps
press Ctrl-T for autoformatting your code
do a rightclick with the mouse and choose "copy for forum"