how do you debug the code?

[nigelwright7557]

The best approach is incremental design.
Start off with a small piece of code and convince yourself that is working before adding a little more etc.
Use debugger to view the result of the code.
I usually add an LED to embedded systems to help with debugging.

[nctnico]

Incremental design should go without saying 
You can't make a pie by starting with the toppings.
More often than not you'll find unexpected quirks coming from hardware / sensors that need special attention by the part that implements the logic.

For example: recently I did a project involving radars that can track people. Ofcourse the supplier has very nice videos showing that these radars track persons perfectly but the reality is that the radars do lose a person rather quickly so this needed some additional work in the software to do some matching.

[T3sl4co1l]

Well, both.  You also can't make a pie by starting with fruit, sugar, flour, etc.  Hm... admittedly, you can make a lot of tasty or at least nutritious things with those ingredients in fairly random amounts and order... but, needless to say programming is a bit more complicated (and picky!) than pastry.   So to make a..."pie", you need to start with the notion of making a pie, and then how to assemble it, and so on.  Hence: top-down, bottom-up design.

The solution for the top-level problem needs to be informed by knowledge (or if lacking, research -- early development or PoC) from the bottom -- which peripherals you can use, how much CPU they'll take (ISRs, etc.), how much logic or other things you'll need to fill in the gaps (HW vs. SW support for various functions, housekeeping, etc.; stuff like buffering or DMA), and then overall program code on top (the "draw the rest of the fucking owl" part ).  Do some top level planning, bottom level implementation, and gradually fill in between.

Which is also suggestive of a layered architecture: do drivers, with whatever degree of abstraction you like/need, at the bottom; then layers of "kernel", application, etc. on top of that.

Which, most embedded stuff probably doesn't go very deep, but when it does, you'll likely choose something to help manage that; RTOS or Linux say.  Ingredients in the solution will naturally reflect the structure and scale of the solution.

Tim

[PlainName]

I don't understand what is the best way to debug c code.

Same way you debug anything. The tool you use to zero in on the cause comes later.

What is your general approach for any compiler to c debug code ?

First, you gotta figure out what the problem is you're wanting to solve. Sounds the easy part but typically all you know is that something that's expected to happen doesn't, or something unexpected happens. But what, exactly, is that? Suppose your LCD displays "42" instead of the expected "On" or something - what's actually gone wrong there?

If you have access to a single-stepping debugger the temptation is to set up a breakpoint just before the print function and then, when the code halts, check the variables or strings. Maybe if you don't have that kind of debugger you'll just shove a load of printf statements around to try and capture the thing going wrong.

I would suggest those are the wrong approaches at this point. Instead, you should think about what the fault could be. Does it happen all the time or just when certain values are displayed? Maybe when a certain GPIO pin is toggled? A timer rolls over? I would usually look closely at what else is happening and just collect a lot of data. There might be other things that aren't actually wrong but, you know, not quite right. Perhaps a glitch just before something is displayed, or something taking longer (or shorter) than it should. Forget about whether it's related to the fault you can see and just collect info.

Then you play with that in your mind and figure out what kind of thing could affect all of that info you have. Clearly, the more info you have the better chance of it all pointing to something common, or a likely suspect. Now you've figured the likely cause you work out how you can prove that using the tools at your disposal. Clearly, some tools are easier to use than others, but a simple LED can be as informative as a breakpoint or printf if you know what you want it to say.

Sounds a bit long-winded, but the technique is pretty simple, reasonably quick and should apply to most fault-finding scenarios.

[As an example, our hot water overflow is currently overflowing dramatically and the cause could be one of two issue - a cheap one replacing the thermostat or an expensive one replacing the tank. I figure if it's the expensive one (heating coil corroded leading to boiler circuit leaking into hot water tank) then using the immersion heater instead of the gas boiler will not provoke the issue, and sure enough it doesn't . There, collecting info and applying a simple test shows the cause where the equivalent of single-stepping would be to drain and dismantle the tank, or change the thermostat just to see.]

[RJSV]

Yeah mk14 has it right, (back a couple of posts). I would add to that you could set a breakpoint on some error catching code you've included; that is somewhat equiv to using printf(). But the context, in real time interactions, with serial ports, etc. might preclude just general use.
   I think strong point, here, is when you can get a really specific case, where some time-out or other process isn't behaving as predicted.  THEN it's a good time to get onto post your very specific confusion / unexpected result.  I think, rather than a general 'this before that' question.  Those, you could try guess which is best order.  Try both ways.  (But my guess is you would enter your debugger first, then set breakpoints).  Usually it's not a general thing, but one specific breakpoint, as you focus on one specific area of problem.  If it's 3 different breakpoints that's maybe too 'general' an approach...if that makes sense.

[Siwastaja]

1)
Read and UNDERSTAND the code, in your head. If you can't understand the code you wrote yourself, re-write it until you can. This reduces number of bugs to manageable level. This is important because each bug might take hours to find and fix, on average.

2)
Add instrumentation. Simplest is so-called printf debugging, or more properly, if(logging_level > 42) fprintf(log_file, "we are at x, i=%d and asdf=%08x", i, asdf);
For more timing critical thing, you can do like
typedef struct
{
    int16_t current:
    uint16_t voltage;
    uint8_t return_code;
    uint8_t next_state;
} log_elem_t;

log_elem_t log[LOG_LEN];

Just fill the log somewhere (where you cannot print due to timing etc) and dump it out later. This continues working in production, unlike attaching JTAG based debugger on lab table!

Especially useful: if you have a state machine: in a function which changes state, log previous and next state along with some other variables. You can also record some free-running counter to get idea of time.

3) Add error checks, range checks, sanity checks - basically asserts. Even in embedded:
if(x < 3 || x > 7) error(6); // x should be within this range because of asdfg, and latter code assumes so.

This works in production, too! Make the LED blink 6 times and ask the customer to count the blinks. Catching wrong function argument by a clear error message only takes a minute; having to debug some overindexing issue or similar can take days.

All of this is not that much work, and once you spend the few hours initially, it sticks to your codebase and continues being helpful when you least expect having any problem.

[Picuino]

I never use interactive debuggers.

Me neither.
With microcontrollers I use a combination of:

   * printf()

   * switch_output_pin() + oscilloscope or multimeter

The second method is better for processes that are fast and may be affected by printf delays.
For example you can switch the output of a pin on the input and on the output of an interrupt and thus clearly see the execution time of the interrupt and the total time it takes up.

[Siwastaja]

   * switch_output_pin() + oscilloscope or multimeter

Also, SPARE_UART->TXDR = 0x57;

This gives you both timing (nearly if not as accurate as GPIO), and any 8-bit tag or other data attached to it, which you can see on the oscilloscope decode function, in sync with any actual analog measurements you are doing off the same system. And it's still just a few lines of code and one-two register write(s) which is unlikely to mess up any critical timing.

If I have a spare LED and some complicated ISR, I routinely just enable the LED at the beginning and disable at exit. This way, it's obvious to the eye if the ISR ever gets stuck (during early development), and you can eyeball the % of CPU time spent in ISR from the LED brightness. Then you can just probe the LED pin with oscilloscope probe tip to get exact timing without having to remember where you did route the signal, because it's just the LED.

I like simply but powerful small tricks like this. Variations are endless, all you need is a bit of creativity.

[DiTBho]

The truth is in the middle. Printfs are definitely handy for printing status information.

Yup. I don't need printfs, my ICE uses communication channels and inspection points.

[Siwastaja]

+ do unit testing of state machines and algorithms on PC, instead of just writing long pieces of complex code for MCU target only to be tested on that tiny CPU. On PC, you can just loop through all interesting combinations and log the output and decision process to a csv file, for example.

[rstofer]

I never use interactive debuggers.

It wasn't a good technique 40 years ago when CPUs ran 250 thousand instructions a second and I could press the "step" button realistically once or twice a second.  It's a MUCH WORSE technique today when desktop CPUs run in excess of 10 billion instructions a second, per core, and interact with the real world (other machines) in very timing-dependent ways.

Put printf() or some equivalent at interesting parts of your code, either simply saying "I am here now" or also printing the values of interesting variables.

Don't let anyone tell you that's a crude or beginner's way to debug. It's the professional's way.

The only reason to ever use an interactive debugger is perhaps if your problem is not that your program is misbehaving but that you simply don't understand how a programming language works.

I remember using Digital Research's DDT debugger way back around '78.  I sure won't be doing it again.  As you said, use printf() for tracing program flow.

When I start a uC project, the very first thing I do is get a UART running.  That is always Step 1.  Then I go to "The C Programming Language, First Edition" (Kernighan and Ritchie) and rip off the conversion functions like itoa().  These are simple functions and don't require a heap.  I have a collection of these functions for displaying nibbles, bytes, shorts and words with and without the leading 0x for hex values.  Combined with a puts() function, I can now create all the debug messages I need and I don't need to use the C library and its string functions which likely require a heap.  I avoid a heap at all costs.  Note that I don't actually have, or use, a real printf() function.  I just build strings per K&R and use puts() to display them..

I can surround the debug print statements with #ifdef DEBUG ... #endif to disable the printing while leaving the code intact.  Or I can remove it but sure enough, I'll find I still need it! 

[PlainName]

To answer the specific debugger use questions (which are generic answers, modified by your specific tools):

Should I set a breakpoint after pressing the debug button or set a break point first and then press the debug button?

Typically you will know where you want to start stepping through your code, or where you want to stop to examine, say, variables. So you would set your breakpoint and then start the debugger. The downside to this is where you want to stop on some commonly called function, which may be called 200 times but different processes before the time when you actually want to debug it. In this case you would run the debugger up until close to the right time (or set a breakpoint in the process you know will call your suspect function just before) and the halt, set the breakpoint, continue.

There is step in and step out button while debugging how to use it? should i stop the program then continue press step in button

Step in typically enters the function about to be called and then continues stepping through that function. There should be a step over buttong too, which just runs until the called function returns (that is, it steps through the code at the current level and doesn't step through any called functions).

Step out is used when you're stepping through a function and decide you don't want to any more (that is, go back to whatever called this one). You could keep stepping until the current function returns, but if there are a lot of steps to go then step out shortcuts them all and skips to just after the return.

[peter-h]

Quite often, the only way to solve something is to waggle a GPIO pin and watch it with a scope. In fact I have a scope (Lecroy 3034) permanently wired to my target for this purpose. There is an LED on that GPIO but if it lights up only for 5us, you won't see it

I remember using Digital Research's DDT debugger way back around '78.

I implemented CP/M 2.2 on several targets and never used that horrid tool Back then, it was usually a debug string sent to a serial port. The really key thing was having a decent size tx buffer on it so the debug statement didn't hold up the target.

[T3sl4co1l]

Oh and not to be exclusive -- there's always both.

This's been alluded to, in earlier replies I think, but yet another example is adding check code in your program, which normally falls through so has very little effect on program execution (even only a small cost to execution speed), but within which the code can set a breakpoint so not only can you "printf()" the condition but you can sniff around with the debugger at the same time.  Maybe a combination of approaches might be used.

Example, say you have a nested loop that's iterating over data, and in the output you can clearly see it's made an erroneous translation or whatever, but you can't really be quite sure where/when the error occurred.  So you log output from earlier and earlier steps in the computation, add asserts, range checks, etc., anything to help figure out where the error occurred.  You start with a big heap of data, you might produce even more data as you're collecting additional evidence at first; gradually, you close in on the problem.  Then you are able to reduce the pile of evidence to the smoking gun, one single statement, or index or pass or whatever, which was meant to perform one operation but did something else (overflow or rounding, say); or, say a function got sent erroneous data, or ran out of data, and sent back an -- entirely reasonable return value, but one you merely didn't anticipate encountering in the process, so you forgot to handle that edge case.  All sorts of things.

Well, you might approach such a problem by short-circuiting part of the process, tracing it up until you find the first inconsistency.  You're momentarily making the output worse, less correct, outputting intermediate steps -- but as long as you know what the data are supposed to be, you can find the discrepancy.  This might be by printf() logging, might be dumping to an array, might be stepping a debugger -- maybe all the above.

Case in point, while I don't use debuggers for embedded -- mainly because I don't have any for my current platform -- I try to make good use of them elsewhere, like, I'm fond of using JS for side tools -- calculators, image processing, code generation, that sort of thing.  And often I make use of all the above.  Values can be logged to console; arrays can be queried with various sorting, regex, etc. functions; objects can be passed through partial steps by copy-pasting code into the interpreter (immediate) window, etc.  And object views are all handy, see all the properties, arrays, etc. of variables in current scope.  Best of all, you literally don't have to go anywhere to do this: JS is all right there in your browser, just hit F12, it's literally right here right now!

Tim

[Nominal Animal]

To be clear, I agree with others above: just because I don't often use debuggers, does not mean they aren't useful.

If one uses gdb, then one can even write Python pretty-printers (example includes a Python function to use Graphviz to display an in-memory binary tree at debug time), which for sure can be handy.

It's just that there are many, many different ways to debug code, and they all start at understanding the intent of the developer separately from what the code actually does.  This is why I personally so emphasize Eyeballs mark II.  (And, also the reason why I tell new programmers to learn how to write comments that describe their intent, instead of what the code actually does.  I only wish I had learned to do so too when I learned to write code; it is darned difficult and slow to learn to do it afterwards... just like security, it just isn't something you can bolt on afterwards; it has to be designed in.)

Personally, I consider basically all of the above as useful suggestions.  As each human is subtly different, the "optimum" debugging tool varies from person to person –– and really, from target to target and project to project! ––, so try several, and find whatever seems to work best for you.  Just don't get stuck on one, and periodically, try the different ones to see if they then work better.  (That's what I did at the above GDB link for myself, some eight years ago.)

[rstofer]

For uC and especially for FPGA work, wiggle a gaggle of pins and catch them with a Logic Analyzer.

For one FPGA project, I threaded a 32 bit debug bus through most of the components and commented it out where is wasn't used.  Of course I was still limited to a single driving signal but that worked out fine.

It is, however, problematic to use 1-hot encoding of an FSM with over 100 states and try to capture state information.  Instead, just set the debug bus to some unique value in each state (or even a subset of states).

One trick:  When you write the C code, be thinking about how you plan to debug it.  Build the debug capability in from the start.

[Nominal Animal]

For uC and especially for FPGA work, wiggle a gaggle of pins and catch them with a Logic Analyzer.

As an aside, the 8-channel 24MHz logic analyzers (Saleae logic clones) you can get for ~ $10/10€ off eBay, work really well with PulseView from the sigrok suite (free and open source, binaries available for Windows, Mac OS, and Linux; although I recommend Linux users to use the one in their standard repositories if possible).  The logic analyzer itself is a direct implementation of the Cypress FX2LP USB chip datasheet, and PulseView/Sigrok uses its own FX2LP firmware, so if you rip out any sticker referring to Saleae Logic, you will not even in principle hurt anyones intellectual property.  Pulseview has many decoders built-in, and you can do your own if you want.  It is limited in its sampling frequency, but if your signal clock is not more than a couple of MHz, these cheap devices will serve you well.

[gnuarm]

I don't understand what is the best way to debug c code. What is your general approach for any compiler to c debug code ?

Should I set a breakpoint after pressing the debug button or set a break point first and then press the debug button?

There is step in and step out button while debugging how to use it? should i stop the program then continue press step in button

The way I debug C code is to write Forth code.  Forth is good for breaking your code into small pieces which can be tested interactively and separately.  So you make building blocks, each of which is tested, and construct larger and larger tested blocks until you've created your application. 

This is much harder to do in many languages, like C.  In C, people typically write a large chunk of code, then look for tools to make it easier to deal with the complexity. 

Forth is also very good for small MCUs, because the code tends to be more compact from code factoring and reuse within the application.

I've never needed a debugger to deal with my Forth programs.  A logic analyzer can come in handy when dealing with the hardware. 

[Bassman59]

For uC and especially for FPGA work, wiggle a gaggle of pins and catch them with a Logic Analyzer.

As an aside, the 8-channel 24MHz logic analyzers (Saleae logic clones) you can get for ~ $10/10€ off eBay, work really well with PulseView from the sigrok suite (free and open source, binaries available for Windows, Mac OS, and Linux; although I recommend Linux users to use the one in their standard repositories if possible).  The logic analyzer itself is a direct implementation of the Cypress FX2LP USB chip datasheet, and PulseView/Sigrok uses its own FX2LP firmware, so if you rip out any sticker referring to Saleae Logic, you will not even in principle hurt anyones intellectual property.  Pulseview has many decoders built-in, and you can do your own if you want.  It is limited in its sampling frequency, but if your signal clock is not more than a couple of MHz, these cheap devices will serve you well.

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.

[rstofer]

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...

[Mechatrommer]

The only reason to ever use an interactive debugger is perhaps if your problem is not that your program is misbehaving but that you simply don't understand how a programming language works.

how is that possible? you make a conclusion about what an interactive debugger is if you....

never use interactive debuggers.

? i lived with VB6's (and to some extend MSVC++) interactive debugger for decades, that makes me still dont understand how a programming language works? please explain why i still dont understand? (i may not know what i dont yet know) but in embedded field i have to improvise my debugging technique because the IDE's for embedded MCU's dont provide me interactive debugging as good as VB6, not even close, in ALL of them.

[brucehoult]

The only reason to ever use an interactive debugger is perhaps if your problem is not that your program is misbehaving but that you simply don't understand how a programming language works.

how is that possible? you make a conclusion about what an interactive debugger is if you....

never use interactive debuggers.

? i lived with VB6's (and to some extend MSVC++) interactive debugger for decades, that makes me still dont understand how a programming language works? but in embedded field i have to improvise my debugging technique and the IDE's for embedded MCU's dont provide me interactive debugging as good as VB6, not even close.

Almost never.

I used them in the 80s when I was a n00b. I occasionally use one when learning a new language that is quite different to ones I already know. I use them when a customer sends a core file from a crashed program. Sometimes I use one to binary patch a running program.

[nctnico]

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...

Xilinx' internal logic analyser has been around for decades. It is available to use with ISE but I don't recall whether it is a paid option or not. The biggest downside is that the internal logic analyser eats away precious internal memory and there is little of it so the trace isn't very deep. In general I try to bring a few pins to the outside to attach an external logic analyser. Many of my more complex FPGA designs have additional logic to bring debugging information (status of pins, statemachine states) to the outside by using a mux that can de set to bring out a specific set of signals. By having no timing constraints on these signals (it is easy to see what is what), this method doesn't consume much in terms of scarse resources.

[Mechatrommer]

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?

[Siwastaja]

1) your programs are too simple to not require in depth debugging...

In-depth debugging of complex programs is real PITA with general purpose debuggers (single-stepping, breakpoints, watch lists).

Complex programs have complex interactions and state history, which absolutely requires built-in instrumentation and logging - unless you are of course perfect and never make any mistakes*.

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. Then they come on EEVBlog forum and claim to be world-class experts because they have 2 years of experience on working with STM32 or whatever.

Obviously, sometimes there are cases where adding a breakpoint is just the right thing to do, though.

*) which is a good target even if unachievable; Nominal A's remark of Eyeball mark II is excellent. By just spending 5 more minutes looking at some weird loop and unrolling it in your head, you can easily save hours of painful troubleshooting by never introducing the bug in the first place.