Electronics > Microcontrollers

how do you debug the code?

(1/32) > >>

Dadu@:
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

Ian.M:
That's going to be IDE, toolchain, hardware debugger and device dependent.   As you haven't told us what you are using the only applicable answer is "Do what works!"  |O

If you want a more general answer, how about:
42

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

MK14:

--- Quote from: Dadu@ on June 18, 2022, 11:10:48 am ---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

--- End quote ---

Ignoring the politics, of if and when, debuggers should be used, here is an example of how to use a debugger.

Let's say you want to produce a list of prime numbers, and at some point, it starts outputting obviously wrong, negative numbers.  (Assuming your debugger has this feature), you can set the breakpoint, to be a conditional breakpoint, set to activate when prime < 0.

Run it, until the conditional breakpoint stops the code, then hopefully, by looking around the code (and variables values), can help you see what has gone wrong.  If not.  You can look at what the loop counter was set to when the prime variable became negative.  Let's say it had reached 10,001 when the apparent bug, occurs and primes suddenly became negative.

You can now set the conditional breakpoint, to be loop_counter >= 9,998.  Restart form the beginning and let it run, then use the single step features, to watch the prime variable become negative, and then hopefully see what has gone wrong.

It can get very fiddly and time-consuming, continually pressing the single-step (into) feature.  So, if you see it call a function, which you think is 100% perfect, and completely unrelated to the likely bug you're trying to find.  You can use the step-over feature, to keep in the same place, within the source file.  I.e. it will 'instantly' run the function, and return to the next line in the source code, without you needing to press the single-step (into), button/feature, perhaps hundreds of times.

N.B. If we really are talking about microcontrollers (the opening post seems to be rather short on specific details), then as previously suggested, printf, can be a better approach.
As well as printf, turning on or off, specific ports, possibly also connected to indicator LEDs.  Can also be helpful/necessary, especially if complicated peripheral setup conditions are really the issue.  It also means you can check the timings with a scope, as necessary.

As a rule of thumb, it might be best to think of using a debugger, as a tool of last resort.  Unless you are specifically trying to learn how to use them, or other possible reasons.

T3sl4co1l:

--- Quote from: brucehoult on June 18, 2022, 02:33:44 pm ---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.

--- End quote ---

Indeed there's even merit in just logging everything you can get your fingers on.  This isn't so feasible with limited RAM or slow comms on a real time embedded system say, but when you are able to collect a wide swath of things, take advantage of your other tools -- dump it into a database, or run filters or regex or whatever on it -- look for outliers, race conditions, faulty calculations, etc.  Examples: function inputs/parameters, steps of calculations, interrupts, main() loop stuff, etc.  Perhaps including timestamps, if you have a reasonably useful timer/clock to use that way.

With enough bandwidth, you could log some megabytes of data very quickly (seconds)... which is a terrifying amount for just a little MCU or something, but a pitiful embarrassment to any PC in the last couple decades.

Compare with some of the debugging/monitoring tools on PCs themselves -- Windows procmon for example, hooks all system calls -- thousands per second, and who cares, you've got GB of RAM to hold onto all that!

Tim

Navigation

[0] Message Index

[#] Next page