how do you debug the code?

[brucehoult]

Almost never...

so either:
1) your programs are too simple to not require in depth debugging...
2) or you are genius your programs just work the first time you code them however long they are.
3) or you are diligent type (like most people in pre 70's before computer exist) who do the mental program flow in your head by reading your code line by line, write side notes if neccesary, correct them and redo, until it works?

You forgot

4) implement one tiny feature at a time, and then test it to make sure it works (and didn't break anything else) before moving on to the next tiny feature. Have a running program at all times, starting from HelloWorld.

[Mechatrommer]

man i feel bad that i just jumped in without reading the 2nd page

4) implement one tiny feature at a time, and then test it to make sure it works (and didn't break anything else) before moving on to the next tiny feature. Have a running program at all times, starting from HelloWorld.

a very slow process imho... i prefer code first and debug later. of course experience needed, that i already have few working modules/functions to reuse in a specific program that modules/functions will interact differently specific to the program needs. that "specific" part is what needs debugging. but then... "testing" a small unit/feature in earlier stage will requires "debugging" anyway. but granted, using different strategy other than interactive debugging.

[Mechatrommer]

Single-stepping in a debugger is 99% used by beginners who totally struggle understanding basic concepts of language and resort to this slow and painful process.

we single step (breakpoint, watch variables) at where the program is misbehaving, that we cant make out the reason why by simply thinking about it alone, not single step everything.

It's really up to personal preference and which you find work better for you. Most engineers will use both but favor one much more than the other.
The most annoying thing about using a debugger is those situations where the problem goes away as soon as you enable the debugger and try and catch it. 

this is what i figured when programming mcu world. it opened a new field of headacheness especially the... interrupt routines, and the ever changing registers state based on external conditions (pin change etc), not anything from the code, making interactive debugging technique being rendered almost useless in these systems. anyway, i dont usually use printf/uart technique because mostly i program tiny chip tiny flash, cant afford space to put printf/uart in there. i use sort of simple serial binary GPIO on off spitting technique to debug registers/variables values etc, but for interrupt routines, i dont find any debugging tools in IDE can solve anything about most of it, i have to imagine some "axioms" and device a code to trap something to prove or disprove the axioms ymmv.

[MK14]

You forgot

4) implement one tiny feature at a time, and then test it to make sure it works (and didn't break anything else) before moving on to the next tiny feature. Have a running program at all times, starting from HelloWorld.

There isn't one, perfectly right or wrong (one size fits all) way of sorting out debugging issues, with software development.  There are all sorts of ways, different developers, at different times, solve their issues.

It's like trying to argue, that your favorite brand/type of Coffee/Tea/Whatever, is the best one, and everyone should drink it.

Sometimes the test target hardware isn't available for a period of time, so (unless you want to add the time consuming step of creating emulators or simulators), most of the testing, can't occur, until long after the software has been written.

In some cases, you can knock together a development board and some bits and pieces, to try out the software early.  But a decision may be made, to just press on, and finish the software and leave testing until when the new populated PCBs, are ready.

[PlainName]

Single-stepping in a debugger is 99% used by beginners who totally struggle understanding basic concepts of language and resort to this slow and painful process.

I strongly disagree with that. If an ICE is available I would probably use that to examine state or data at a suspect point because it's quicker and simpler than inserting printf's and other similar debugging tools. Also doesn't affect the code - adding more strings and affecting the stack/heap isn't always innocuous.

Further, if I knew the exact problem I wouldn't need to debug, so a printf will either confirm or point to something else. Another round of inserting data and code, but with the ICE and I can check it out right there and then. And not have to do another recompile because I forgot the damn % in the printf. And then, after all that, remove the just inserted debugging code.

[free_electron]

in order of preference :
- a language that lets me interactively view and edit code / data without having to recompile or restart or dataloss , let's me alter the instruction pointer and add /remove / rerun lines of code. Something like visual basic.
- Hardware emulator with full control of all memory and registers that can trace at source level (we're talking bond-out processors that can go full speed and have dual ported memory so you do not stop or slow down the thing while running.
- an ICE that can do similar to a hardware emulator. Something like Realview ICE or Dstream on Arm. uses dedicate trace port on processor
- dualport ram with a backdoor
- Jlink or jlink style device that lets me explore all memory so i can prod around in there.
- scope / logic analyser , prefer a MSO (analog+digital)
- wiggling pins

printf ? i'll resign ! if you can't afford any / mix / all of the above and i have to waste my time with printf .. i'd rather be unemployed

[Siwastaja]

Single-stepping in a debugger is 99% used by beginners who totally struggle understanding basic concepts of language and resort to this slow and painful process.

I strongly disagree with that. If an ICE is available I would probably use that to examine state or data at a suspect point because it's quicker and simpler than inserting printf's and other similar debugging tools. Also doesn't affect the code - adding more strings and affecting the stack/heap isn't always innocuous.

Further, if I knew the exact problem I wouldn't need to debug, so a printf will either confirm or point to something else. Another round of inserting data and code, but with the ICE and I can check it out right there and then. And not have to do another recompile because I forgot the damn % in the printf. And then, after all that, remove the just inserted debugging code.

There is no need to disagree because you confirm what I say. Quick and easy checks - i.e., something "needed" most by beginners. For someone more experienced, number of these quick and easy checks go down (not to zero of course), and problems become more complex and more difficult, mostly.

Obviously "printf debugging" does not refer to printf itself. I use it in MCUs very little. If you don't like %formats, do not use it.

And "doesn't affect code" is 110% bullshit beyond being funny. Technically might be correct - does not affect code, given that you compile with same settings. Practically wrong because you don't do that - usually we compile with different settings (e.g., -O2 vs. -O1 -g). Also fundamentally wrong - affects peripheral state in difficult to predict ways and causes endless misery among beginners. Also affects timing. Instrumentation of the code itself also affects the code but in much more controllable and predictable way: for example, store a copy of UART data register in one place, instead of letting your ISR and debugger to race whoever reads it first (spuriously clearing flags as side effect).

[SiliconWizard]

Looks like one of those topics that are highly sensitive and triggers very opinionated reactions bordering flame wars. (Apparently, programming is an ideal target for those topics! I've rarely seen "general" programming topics not ending with fights.  Let's be happy though when there's no personal attacks or name calling. )

This is also a frequently discussed topic, so we're all likely to repeat ourselves a good deal.

I personally agree with Siwastaja and Bruce here. I haven't used an interactive debugger on embedded devices for literally ages, and use one very infrequently for "desktop" programming (like maybe a couple times a... year.)

Debugging in general, and not just for software, is all about 1/ observation and 2/ being methodical. There are tons of ways you can "observe" the behavior of running code. The "right" one to use all depends on the context. As to being methodical, interactive debugging rarely promotes it. But if or when a debugger is appropriate for observing a particular behavior that you can't otherwise pinpoint, sure, use one! I just tend to use those as a last resort rather than as first intention.

The (almost) only case in which I'll fire up a debugger like gdb is when the code is crashing. The debugger will locate the line where it happens which will save you time. Once it's located, you may or may not step through the code - depends on the context - but usually, just the backtrace and looking at variables/parameters is enough to proceed, and then you can quit the debugger and go from there.

Of course, some development methods make it less likely you'll run into intractable bugs requiring stepping frantically through code in a debbuger, such as testing relatively small parts of your code as you write it, and proceed incrementally, as Bruce suggested. It again can/has to be adapted to the particular project, your coding abilities and the complexity of the code. Unit testing at too fine a grain, or on trivial functions, is useless and silly: use common sense.

Another development "method" I routinely use (and which I regularly "promote") is parameter validation. Validate functions arguments. It's a tremendous help. Here again, use common sense though.

Tracing using some logging/printf/whatever is of course also useful and usually more productive than manually stepping through code.

While overly generalizing is rarely relevant, resorting to an interactive debugger instead of using one of the above methods (or others of your choice, by no means exhaustive) *can* be a sign that you favor "instant gratification", while using other methods often takes a bit more time upfront, but once done, that can (and usually is) a big time saver at the end of the day. Again not to generalize, but I would say that it is a bit akin to people who have a tendency to copy/paste code repeatedly to achieve a given task rather than pause for a moment and factor code so that the end result is much more maintainable, a lot less prone to errors and will save you a lot of time down the line. Yet some people, from my experience, tend to see this as a waste of time.

So, yeah. My 2 cents.

[nctnico]

I'd like to highlight 'Validate functions arguments'; (very good that SiliconWizard brought it up  ).
I'm doing this in my code at module interfaces (APIs or public members). This creates compartments where errors can not escape from. It makes software fail in a predictable way instead of having a huge oil stain caused by a domino effect from faulty results that travel through a whole bunch of software layers.

Another good tool to know is valgrind. It can do a detailed analysis of memory allocations & frees to check whether all the memory that gets allocated also gets freed. It is a massive help to find memory leaks.

[Bassman59]

In the FPGA, attach an embedded logic analyzer to the signals in question. There's no need to bring them out to pins. Well, unless you're in a small FPGA and you've used up all of your block RAM, but ... then you've probably already used up all of your pins.

And all that said, any unused pin in the design really should be accessible on the board in some manner for use as a debug point, or at least a place to solder on a bodge wire because you missed something.

That Integrated Logic Analyzer is a neat feature of Xilinx Vivado that wasn't available with ISE.  It's great and, as you point out, it doesn't require hardware resources (pins).  I need to play with it some more...

In ISE it was called ChipScope, and seriously it was the best bit of software Xilinx ever implemented. It worked as advertised, no muss, no fuss. Just run the Core Inserter, pick the signals to analyzer, let the fitter run, and off you go.

[PlainName]

There is no need to disagree because you confirm what I say. Quick and easy checks - i.e., something "needed" most by beginners.

OK, perhaps I misunderstood. The drift I got was that only beginners would use those tools; real programmers would pass 'em up (maybe they're too easy). I guess a bit like beginners would use VB whereas serious programmers wouldn't.

[Although, having said that, I once used a fantastic program written in VB. Unfortunately the developer saw the light and decided to rewrite it 'properly' in C#, and it's been pants every since ]

[PlainName]

Another development "method" I routinely use (and which I regularly "promote") is parameter validation. Validate functions arguments.

Yes, all that kind of stuff is good. But that isn't debugging as I gathered the OP wanted to know about - it's preventing the need to debug. I understood the question to mean: it's broken, what do I do now?

[nctnico]

Another development "method" I routinely use (and which I regularly "promote") is parameter validation. Validate functions arguments.

Yes, all that kind of stuff is good. But that isn't debugging as I gathered the OP wanted to know about - it's preventing the need to debug. I understood the question to mean: it's broken, what do I do now?

Learn 'design for testability' 

[MK14]

Another development "method" I routinely use (and which I regularly "promote") is parameter validation. Validate functions arguments.

Yes, all that kind of stuff is good. But that isn't debugging as I gathered the OP wanted to know about - it's preventing the need to debug. I understood the question to mean: it's broken, what do I do now?

No, it sure is part of testing, debugging and software quality assurance/validation.  Otherwise, the software could be silently broken in some places, which can bite you in the foot, if just left there, undiscovered.

[tellurium]

I'd like to highlight 'Validate functions arguments'; (very good that SiliconWizard brought it up  ).
I'm doing this in my code at module interfaces (APIs or public members). This creates compartments where errors can not escape from. It makes software fail in a predictable way instead of having a huge oil stain caused by a domino effect from faulty results that travel through a whole bunch of software layers.

Another good tool to know is valgrind. It can do a detailed analysis of memory allocations & frees to check whether all the memory that gets allocated also gets freed. It is a massive help to find memory leaks.

Params checking, valgrind, and testing are invaluable tools.
Another one worth mentioning, is  cheap to use but very effective: compilation flags. This article has a good overview and explanations: https://interrupt.memfault.com/blog/best-and-worst-gcc-clang-compiler-flags

For example, an (arguably) rarely used -g3 GCC/Clang flag pulls enum / macro definitions into the debugger interactive session.

[SiliconWizard]

Another development "method" I routinely use (and which I regularly "promote") is parameter validation. Validate functions arguments.

Yes, all that kind of stuff is good. But that isn't debugging as I gathered the OP wanted to know about - it's preventing the need to debug. I understood the question to mean: it's broken, what do I do now?

No, it sure is part of testing, debugging and software quality assurance/validation.  Otherwise, the software could be silently broken in some places, which can bite you in the foot, if just left there, undiscovered.

Yup. Some people even only do parameter validation for testing/debugging purposes instead of doing it at all times even in release mode. Often through the use of assert().

I personally do prefer to leave parameter validation everywhere it makes sense, at all times, and not just in "debug" mode. Hoare wrote:

"What would we think of a sailing enthusiast who wears his lifejacket when training on dry land, but takes it off as soon as he goes to sea?"

[free_electron]

so how do you debug a system that does not have a communication interface ? or when you are trying to make it work ?
you get a new processor and there are no libraries. Here is the register map and datasheet ...
your code compiles but all there is is silence. nothing comes out of the uart or usb or whatever...
what do you do then ? printf into the stetoscope? warm finger test ?

[MK14]

so how do you debug a system that does not have a communication interface ? or when you are trying to make it work ?
you get a new processor and there are no libraries. Here is the register map and datasheet ...
your code compiles but all there is is silence. nothing comes out of the uart or usb or whatever...
what do you do then ? printf into the stetoscope? warm finger test ?

One way is to turn port pins on/off, in a pattern, to show where in the code, it has successfully reached.  Moving it backwards or forwards, until the problem/crashing point has been found.  Actual hardware, may have features, changing what I just said, such as alternative output mechanisms, such as LEDs or sounders.

[free_electron]

and if you don't have free port pins ?  they are all in use ?
get a damn jtag probe or an ice. printf is for pdp-11.
and on a tight system where the rom is nearly exhausted : do you really want to put debugging code in there ? and who's going to debug the debugging code ?
it is a waste of effort, time and system resources.
Jtag dongles are cheap. use em. set watches and breakpoints , examine memory, change contents , single step , direct call.
I like a large toolbox. debugging using only printf is like restricting yourself to using only a hammer

[tellurium]

so how do you debug a system that does not have a communication interface ? or when you are trying to make it work ?
you get a new processor and there are no libraries. Here is the register map and datasheet ...
your code compiles but all there is is silence. nothing comes out of the uart or usb or whatever...
what do you do then ? printf into the stetoscope? warm finger test ?

Turn it off and on again..

[MK14]

debugging using only printf is like restricting yourself to using only a hammer

With a hammer, box of nails, suitable pieces of wood and some clever planning/organization.  Rather big and complicated structures can be built.  Such as large sheds (out-buildings).

Printf, is a very powerful method, particularly when combined with incremental development (as already mentioned).

But it is NOT the only way, there are lots of other ways.  As you implied, by saying you have many tools in your big tool box.

The printf method, is not so good, when the problem lies within interrupts, or involves complicated timing and/or peripheral setup issues.  Then there are memory-leaks, and problems/issues outside of the immediate source-code, which also need to be diagnosed (to find out where the real problem lies), but could be outside of the range of where the printf's can be placed (e.g. closed source libraries (can link in) and/or closed source operating systems, etc).

[free_electron]

Turn it off and on again..

yeah , that's how all the crap these days is developed.

[brucehoult]

and if you don't have free port pins ?  they are all in use ?
get a damn jtag probe or an ice. printf is for pdp-11.
and on a tight system where the rom is nearly exhausted : do you really want to put debugging code in there ? and who's going to debug the debugging code ?
it is a waste of effort, time and system resources.
Jtag dongles are cheap. use em. set watches and breakpoints , examine memory, change contents , single step , direct call.
I like a large toolbox. debugging using only printf is like restricting yourself to using only a hammer

Lots of things don't support JTAG, not to mention that if you're writing software for someone else's commercial product JTAG might not be exposed, you certainly can't do ICE etc.

I once did a lot of work on pre iPhone and Android mobile phones running the Qualcomm "BREW" OS where it was extremely easy and common to crash the system and the only debugging methods possible were drawing things on the screen and writing a file to flash. And if the thing crashed then the last X amount of your file logging never got written to the file. Our product had to run on literally a hundred or so different phone models, which we mostly bought used on ebay. Most used ARM7TDMI and ran at 1 MHz or so.

If you're designing your own board and even have a possibility to use ICE or JTAG then you're in a much more privileged position than many of us.

> and on a tight system where the rom is nearly exhausted : do you really want to put debugging code in there ?

If you're in a position where ICE is even an option, then you can probably also buy a larger part for development and then, yes, you can put debugging code in there.

[Mechatrommer]

and if you don't have free port pins ?  they are all in use ?
get a damn jtag probe or an ice. printf is for pdp-11.

what if the mcu no have jtag? why HW developers bothered to provide jtag feature in the first place? it adds nothing to the end functionality of the HW/mcu/ic/fpga right? why emulators/stimulus tools are developed? history tells us... people will develop any kind of debugging tools in order for them to make something works. in all kind of range from interactive debugger, emulators, jtag inline outline debugger whatever they are called, printf/code injection trick (when interactive jtag fails to work) etc, to the HW level debugger such oscilloscope, LA, multimeter, even maybe a resistor can be used as a debugger. when the problem is a nail, hammer is the tool, when problem is the fish, rod or lure is the tool, we dont catch fish with a hammer, but hammer has its place somewhere else. what if we dont have ready made/suitable debugger? we make/invent/improvise our own. what if we dont want to do it? we quit. not everybody has the luxury as anybody else. i have a chance to probe values in VB6 immediate panel, so i'll use it, because i have it. the way i see it, its equivalent to the printf or jtag scan or flipping pins in other environments. imagine how people do it before computers? using brains and mathematics? the precursors of what we have today, no? ymmv. cheers

[tellurium]

Engineers who don't use/trust the debugger very much tend to send debug messages over UART, or flash an LED, or toggle GPIOs while looking at scope/logic_analyser etc.

There is another aspect where printf style helps and interactive debugger does not.
That is, if a device is in the field, and crashes / misbehaves. There, logs can help a lot with forensics.