how do you debug the code?

[Siwastaja]

you dont expect greybearded just came out of a womb in an instance right?

Good point!

Maybe I can help you because my beard is still dark brown. So I remember my beginner days as they are not too far in the past. I remember the phases of getting a better embedded programmer. And the process is still going.

And: I never did that debugger thing, really. The problem is, debugger with all its fancy features seems very convenient, compared to actual printf debugging. I can't prove it, but I suspect many who start that way early get stuck with the debuggers. Being able to connect an existing tool to your code and single-step through it and examine memory causes certain mindset of writing the software.

Compare this to not having a debugger and resorting to printf debugging. At very first, it is literally just
printf("place A\n");
...
printf("place B\n");
...

This is not very powerful. Finding bugs is a struggle. But it sets you on the right track because:
* It teaches you that finding bugs is difficult, because it will always be no matter what tools,
* It teaches you, piece by piece, to write better instrumentation. Because you see, this is easy to improve:
printf("place A\n");
becomes:
printf("i=%5d, coords=(%5d,%5d)\n", i, x, y);

Then it becomes:
if(loglevel > 5) fprintf(log, __FUNCTION__ ":" __LINE__ "i=%5d, coords=(%5d,%5d)\n", i, x, y);

Then you understand to add:
assert(x > y);

Or in MCU ISR, you understand to do this:

if(logging && cur_trace_idx < NUM_ELEM(trace))
    trace[cur_trace_idx++] = latest_measurement;

because this is all you have, you have to work with the code.

And it grows to a mindset of writing robust, self-checking, instrumented code. Which is a very good target, and while it sounds fancy, you can easily grab the low hanging fruits instead of going super complex with this.

And at the end of the day, you may still connect the JTAG and debugger. Last time I did was in 2020.

[Mechatrommer]

i cant differentiate  between "debugger" and "instrumentation" that you said or even with a single innocent through hole resistor, if all of their intent is the same, ie to find fault in your code or invention. only difference is the technique or strategy, and to some extend, different effect (as already being discussed) but they all to debug, or to get rid of a bug (fault), hence a "debugger". and afaik assert is the one used by new kids to learn programming, you all sharp people will eventually come down it anyway (i dont, since after i made my first "real" program) and i remember reading book that assert can be left intact harmless when publishing the program into real world because programmers are to lazy to take care of them in the end, at least thats the impression i got after reading the book. when its triggered, users can unhappily report back the assert msg back to the programmer for the next fix patch. and if its the same as the way assert is executed in SW PC programming, it can be devastating if implemented in life-critical embedded world, no?

[Siwastaja]

Obviously, you need to come up with something assert-like of your own in a life-critical embedded system.

That's one of the hardest parts, recovery after a failure.

In order from worst to best:
1 Do not check for errors / wrong assumptions at all, let the errors propagate
2 assert and die in controlled way with logging
3 assert and recover

The point is, 2 will actually save your time AND make a better product because even if it happens in production, you will fix it faster! It's the obvious low hanging fruit you should just learn to take, yet people often won't, especially if they feel they can "easily" just find bugs on lab table with JTAG probe and debugger.

3 will be actually very difficult and challenging.

In all cases, you would be still "debugging" the code in the general wide sense of the term. Just spending different amount of effort to do it.

[free_electron]

man, jtag is not even mentioned in the list!

ever seen the frontpanel of an ibm360 ? That's JTAG on steroids ! you can see and modify any damn bit in the machine you want. singlestep it, step it forward, step if backwards, call subroutines.
they have large "rollers" on the side. you rotate that and it selects elements and registers in the computer. the contents are shown on little neon lights. The rollers are large electrical switches that also move a paper sheet that shows the function of the lights behind a plexiglass plate.

So yes, debugging from the very beginning was done by examining and tracing in hardware. not by spitting text to a teletype.
JTAg lets you still do that , but over a serialized 4 wire bus as opposed to the hefty bundles of cables going to that frontpanel
You could even modify the power rails of the computer just in case some voltage was a bit "marginal" to make the machine work properly.

[Mechatrommer]

ever seen the frontpanel of an ibm360 ? That's JTAG on steroids ! you can see and modify any damn bit in the machine you want. singlestep it, step it forward, step if backwards, call subroutines.

so i guess jtag is "interactive debugging" on steroids except, interactive debugging can be done on emulator or virtual machine, before it can run on real hardware.

2 assert and die in controlled way with logging
The point is, 2 will actually save your time AND make a better product because even if it happens in production, you will fix it faster!

so i guess assert is not much diffferent from printf, except with a little bit of addition.... if (fault) printf and halt... of course printf is not literally printf that we learnt in c... we can make our own "printf", maybe with different name like "assert" or in my case... "sendByteSerialTx" for my specific attiny project. similarly to when a hardware got overheated for unexpected reason, it halts and blink a red led. thats the debug sign!

[Bassman59]

After six pages of this shit (and counting), it seems like the correct answer to the question is, "Use whatever tools you have at your disposal and choose the one which best gets the bug found."

If that's printf() in code, then so be it.
If that's twiddling an output pin in an ISR, then so be it.
If that's using at JTAG or other debugger to inspect registers and variables, then so be it.
If that's writing correct code in the first place, then so be it.

You don't get bonus points for only using one sort of debug tool. The bosses don't care how you solved the problem. They only care that they can ship product so everyone gets paid.

[Siwastaja]

so i guess assert is not much diffferent from printf, except with a little bit of addition.... if (fault) printf and halt... of course printf is not literally printf that we learnt in c... we can make our own "printf", maybe with different name like "assert" or in my case... "sendByteSerialTx" for my specific attiny project. similarly to when a hardware got overheated for unexpected reason, it halts and blink a red led. thats the debug sign!

Yes, you got it . Incrementally develop new habits that make debugging easier. Let the frustration of bug-hunting guide you.

I prefer multi-interface error handlers. Any error will always come with an integer error code, and error handler at very least blinks the LED n times, using simple blocking delay loops. Almost every project has an LED, and it's accessible with GPIO without other peripherals.

If everything else fails, you can always count the blinks. But the same handler will try to send more detailed information on UART - and not just once, repeat once a minute so that you can keep the thing powered and plug in the cable. If the system is CAN connected, send a report to CAN. Log to SD card if you have one. And so on.

What to include in the report? I like a union of different types of general purpose debug integers that I set in code. I also include control/status registers of some suspicious peripherals like DMA, SPI etc, print a few CPU registers like link register, and a stack dump.

But most valuable is that you just store intermediate values that led into the final result in variables that can be printed in your error handler, or accessed with a debugger if you so like. It is unfeasible to trace the whole memory with a debugger all the time. But if you keep at least a mimimal record about the chain of calculations/decisions, then it's trivial to print them out.

[Siwastaja]

After six pages of this shit (and counting)

Why do you think it's shit? Like you say, the result matters. What is wrong with giving the OP with as many different tools and viewpoints as possible? And if you are so excellent and others write shit, why post here at all? What is wrong with you?

[Bassman59]

After six pages of this shit (and counting)

Why do you think it's shit? Like you say, the result matters. What is wrong with giving the OP with as many different tools and viewpoints as possible? And if you are so excellent and others write shit, why post here at all? What is wrong with you?

Here in the US (and especially New Jersey, where I'm from), when we say, "pages of this shit," we don't mean it in the pejorative. I suppose I could have said, "stuff."

But, seriously, the "shit" is the constant back and forth of "I do it this way, it's the best way, your way isn't any good."

[tellurium]

After six pages of this shit (and counting)

I got elastic bands keepin' my shoes on
Got those swollen-hand blues
I got 6 pages of shit on the forum to choose from

[Picuino]

But, seriously, the "shit" is the constant back and forth of "I do it this way, it's the best way, your way isn't any good."

All of your debugging ways are crap. The only way to do it right is DARYL's way:   

[tepalia02]

I may sound dumb. But for me, printing something in the output terminal helps most of the time.

[gnuarm]

I may sound dumb. But for me, printing something in the output terminal helps most of the time.

When I'm working in Forth, that's called REPL, Read, Evaluate, Print Loop. Maybe it won't work for everything, but it is useful 99% of the time. Instead of complex emulators, a simple serial port does the job.

[pcprogrammer]

I may sound dumb. But for me, printing something in the output terminal helps most of the time.

When I'm working in Forth, that's called REPL, Read, Evaluate, Print Loop. Maybe it won't work for everything, but it is useful 99% of the time. Instead of complex emulators, a simple serial port does the job.

But the problem with Forth is that it requires a backward way of thinking. Don't get me wrong, it is a nice language and I have used it instead of basic on micro's like 8051 and 6502, but now a days with good C compilers and fast micro's for me it is a bit outdated.

It was certainly fun and easy to do assembly coding with it. I have also used it to mimic a dongle for Xilinx software. Was not that hard, just count a number of pulses and toggle a line at the right count.

[gnuarm]

I may sound dumb. But for me, printing something in the output terminal helps most of the time.

When I'm working in Forth, that's called REPL, Read, Evaluate, Print Loop. Maybe it won't work for everything, but it is useful 99% of the time. Instead of complex emulators, a simple serial port does the job.

But the problem with Forth is that it requires a backward way of thinking. Don't get me wrong, it is a nice language and I have used it instead of basic on micro's like 8051 and 6502, but now a days with good C compilers and fast micro's for me it is a bit outdated.

It was certainly fun and easy to do assembly coding with it. I have also used it to mimic a dongle for Xilinx software. Was not that hard, just count a number of pulses and toggle a line at the right count.

Know I not backwards thinking it is.  Actually, many people object to the one tiny bit of syntax it has, Reverse Polish Notation, RPN.  That is not entirely accurate, really.  The interpreter simply interprets a word at a time, rather than waiting for a line to be digested and turned into machine code.  So the operands are normally first. 

That's not always the case.  A string is created with a word S" which then scans the input for the next quote marking the end of the text.  Many words that create words, look for their input after the word. 

Or did you mean backwards in the Appalachian back woods sense?  I prefer a simple tool.  I'm not designing systems with 27 interrupt priorities.  I design systems to get the job done while making the software easy to debug.  I'd much rather use a screwdriver or hammer, than a pneumatic fastener tool. 

[pcprogrammer]

Know I not backwards thinking it is.  Actually, many people object to the one tiny bit of syntax it has, Reverse Polish Notation, RPN.  That is not entirely accurate, really.  The interpreter simply interprets a word at a time, rather than waiting for a line to be digested and turned into machine code.  So the operands are normally first. 

That's not always the case.  A string is created with a word S" which then scans the input for the next quote marking the end of the text.  Many words that create words, look for their input after the word. 

Or did you mean backwards in the Appalachian back woods sense?  I prefer a simple tool.  I'm not designing systems with 27 interrupt priorities.  I design systems to get the job done while making the software easy to debug.  I'd much rather use a screwdriver or hammer, than a pneumatic fastener tool.

I was hinting to the RPN way of how it operates.

Agree with you that a simple tool to do a simple job is the way to go. Always choose the right tool for the job, but sometimes you have to use what is at hand and try to make the best of it. For example if all you have is a knife and you need to strip a wire and screw it into a terminal it can be done with just the knife.

[Mechatrommer]

this thread reminds me that one of the use of interactive debugger is to run through an external/3rd party/unknown library source code to see/study parameters/variables values or called procedures if i'm too lazy to chart them with paper and brain.. ymmv.

[Siwastaja]

Having to debug code by others which is brought to your project under the name of "library" sucks so hard. Normally you would assume that library is well tested and works correctly, and offers well documented interfaces.

If you really must debug library code, then really all the normal debugging ideas apply. If you don't have the source, it is indeed more appealing to look at the assembly code in debugger and utilize breakpoints/singlestepping, than to disassemble the library and start adding new instrumentation code, in assembly, within it.

But really, at that point you should be negotiating to acquire the source code for the library, and possibly further help debugging it (like further documentation and unit tests used by the original developers, etc.)

[pcprogrammer]

Or you find a solution around it if modifying the library is not possible.

Many years back I had to write asp code and basic script for a web server/page and there was a problem with dates in the basic script. Had to make my own code in basic script to overcome the problem.

But for sure, working on or with code from others can be a big pain in the bum.

[PlainName]

working on or with code from others can be a big pain in the bum

Can be, but it can also be very satisfying - there is to ego boost of having fixed an issue but without the guilty conscience of having written the bug in the first place

[tellurium]

Can be, but it can also be very satisfying - there is to ego boost of having fixed an issue but without the guilty conscience of having written the bug in the first place

Provided you didn't implant a few more, along with a fix

[Mechatrommer]

sometime its not a bug, its just that the original code doesnt work the way i want it but surely works for others. or sometime i just want to know how did they do it, how much memory is going to involve etc. the last time i did it on marlin code for 3d printer. interactive debugger isnt available in that retarded arduino ide so i have to do it by pencil and paper. otoh the funniest thing to me is that every program that i've made (for my own), and i mean every single one of them, when i want to upgrade later in like 3-10 years time is going to be like someone else's code, so i have to retrace and upgrade the code like one... so at some point of time ago, i know how much important the commenting is...

[gnuarm]

Know I not backwards thinking it is.  Actually, many people object to the one tiny bit of syntax it has, Reverse Polish Notation, RPN.  That is not entirely accurate, really.  The interpreter simply interprets a word at a time, rather than waiting for a line to be digested and turned into machine code.  So the operands are normally first. 

That's not always the case.  A string is created with a word S" which then scans the input for the next quote marking the end of the text.  Many words that create words, look for their input after the word. 

Or did you mean backwards in the Appalachian back woods sense?  I prefer a simple tool.  I'm not designing systems with 27 interrupt priorities.  I design systems to get the job done while making the software easy to debug.  I'd much rather use a screwdriver or hammer, than a pneumatic fastener tool.

I was hinting to the RPN way of how it operates.

Agree with you that a simple tool to do a simple job is the way to go. Always choose the right tool for the job, but sometimes you have to use what is at hand and try to make the best of it. For example if all you have is a knife and you need to strip a wire and screw it into a terminal it can be done with just the knife.

Yes, I much prefer to solve simple problems rather than complex problems.  That's why I try to create only simple problems.  I create designs without complex problems and are only left with simple problems.

Even simple problems can be hard to find if your methods are complex.  So simple debug methods are also preferred.

[MikeK]

I usually use very simple methods of debugging, like turning on an LED.  But I also made a simple version of this a while ago.

[nigelwright7557]

You can write loads of code then set about debugging it.
Set breakpoints and create watch variables to see what is happening.
LED's on output pins and use of an oscilloscope if timings are important.

I tend to use incremental debugging.
I write a small module of code then fully debug it before going onto next part.
Its much easier to debug a small piece of code.