how do you debug the code?

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

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

in what age do you live ? any micro out there has either jtag, swd or another form of programming/debug interface , same for FPGA.
HW developers bothered to develop JTAG and SWD specifically to make it easy for the software developers to trace their code and debug. SWD : Single wire DEBUG. got it now ?
Next time someone designs a chip i will suggest the make a single pin for an led available that can blink error codes or you can hook  up a speaker and send out morse code.
and send the program into the device we'll do the same. you can send it in in morse code.

restricting yourself to printf for debug is just plain stupid.

[Mechatrommer]

in what age do you live ? any micro out there has either jtag, swd or another form of programming/debug interface

attiny10-85 age

Next time someone designs a chip i will suggest the make a single pin for an led available that can blink error codes or you can hook  up a speaker and send out morse code.

we've done it in attiny10 thank you! and err, we dont need cryptic morse code... plain 8 bit is "this age". attached is my latest incarnation of it, evolved several times originating from some china radio transmission project.. the drawback is.. you need an oscilloscope..

restricting yourself to printf for debug is just plain stupid

nobody is restricting you. they just give one of the option

[Siwastaja]

"I can't have even a single free IO pin, but I totally can have all JTAG pins" sounds like a made-up bogus argument.

In pin constrained small MCUs, the first thing you'd sacrifice would be the JTAG/SWD and use them as GPIO.

In large MCUs, you would have the luxury of having both JTAG and a "development/logging UART" available.

[mikerj]

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.

A professional uses whatever method is most appropriate rather than constraining themselves to one specific method.  e.g. printf can be an execution time hog that can change the behaviour of the system on slower micros.

If you can't afford the timing changes from a printf() -- and it doesn't have to literally be printf(), it can be as simple as a unique byte put in a buffer or toggling pins on a GPIO port -- then how can you afford a breakpoint?

If you have a timing critical system you obviously wouldn't break on every loop, you'd make the break conditional on the failure mode.

[Siwastaja]

If you have a timing critical system you obviously wouldn't break on every loop, you'd make the break conditional on the failure mode.

Exactly - in other words, if(something_unexpected) {...}. What you are describing is bog-standard intrusive instrumentation. I can't imagine many cases where you can't afford to add that. Of course not printf() within critical loop or ISR, but storage of interesting data, bounds checks, error checks etc. - definitely yes. This is all intrusive, but is also all very necessary. Leaving it all out and hoping to catch error conditions on lab table with JTAG probe + debugger just does not cut it, no matter how much mental gymnastics is being done to paint this "professional approach because bells and whistles like real pro".

And once you realize this, the habit will get stuck. Because at some point you see how much time it saves you to find problems semi-automatically, before you even realized you had a problem, instead of chasing bugs. Oh, error(57) triggered with dbg1=-1259, I see! Good, it would have caused something really weird half an hour later.

Such preventive coding style has allowed to me to start writing much longer pieces of code when I have the right flow of mind: I just codify the assumptions I am making in form of asserts. If I made a mistake, chances are high one of these trigger and dumps out some kind of error report.

[free_electron]

i think you have a serious misunderstanding on how debugging a system using an ICE or TRACe probe works.
Just like you trigger events and send out a debug report the probe is set up to trigger on events and take a snapshot of anything you'd like to see.
The difference is you don't use the system processor to produce the report. The probe does that.
The probe can get to areas where your printf solution cannot go and it can do it without corrupting the processor state. You jump out and start collecting bits and bytes by copying them or starting to send them out using printf. The time it takes to collect and send out the contents , the data may have changed so you never see what is there at the moment of the trigger. This is especially true when you are trying to bring up the HAL or BSP.
i'm going to print out the content of a circular hardware buffer. while you are print'effing the contents of the buffer are still changing. so all you get is useless data.

Another issue is that , If your report produces nothing of interest, you are going through another code, compile, load, run cycle to add other fields that may or may not yield something.

With an ICE and TRACE : if the event fires you have the entire processor state and the stuff of interest in one clockcycle . "Big" processors have trace assist where they can even record many cycles before the trap event. you can replay
Another thing you can do is to call functions of your system.
event occurs -> trap and halt , examine anything you want using the trace without state change (since it is done using a backdoor and does not require processor resources). alter content of data / registers through the debugger then move the execution pointer. You can let the trapped code continue until the exitpoint , halt it again there , set up new data and call the function again , deviating form the normal flow.

Code: [Select]

main :
call some_function (123)
*breakpoint if trapped=true
call some_other_function
...

some_function (int bleh) :
  internal variables x,y,z
  do some stuff here that messes up sometimes
  *trap if condition is met. example y>9
end some_function
If the trap fires in "somefunction" the processor state is saved together with what you want (this is set up in the ice, no need to write code)
You can examine x,y and z.
You find out y is not what it should be. set y to expected value and continue to verify it is indeed the problem.
Or, since the trap fired, continue. now the breakpoint will fire (the breakpoint is conditional : only if the trap fired will the program stop there.
You can now call the function again, manually.
You can interactively just type "somefunction(17)" and the processor will execute that function again. all without the need of recompiling or spending time implementing i/o functionality to fish for data or to invoke functions.

you also do not need to do the endless fix a bug compile, find the next one , compile again.
you can fix things in place and continue the run. Once you hit the point where you can't fix in place then you stop , go fix the source for everything you found.
Emulators let you modify code.
you can create an entirely new some_function, load it in ram and alter the calls so the new some_function is used instead of the old one. no need to recompile the entire program. just the function itself.

it's damn handy to be able, not to just look at things, but interactively modify and execute things while in trap
it's not always a bug per se. it may just be an unexpected or unhandled state . your code is correct but something happens for which you have no logic. something that should not happen, but does. first you need to find  what happened, then why did it happen ? your printf debug style is useless for such cases since you don't know the "what" so you can't code a report generator for it. The ICE is a "catch all".

There's a reason companies pay big bucks for those tools. When i was still doing harddisks every bench and desk had one of those probes. Lauterbach , Greenhills , American Arium.
They key strength is go anywhere, anytime, look at anything and do anything without needing to write debugging code or recompilation / relaunch. fix in place and interactively execute.

[PlainName]

The time it takes to collect and send out the contents , the data may have changed so you never see what is there at the moment of the trigger.

This is an important thing to bear in mind with printf (and similar) solutions: the act of printing can affect the timing of tasks and introduce an artificial speed constraint. Satisfied with your product you remove the debug stuff and suddenly things aren't happening as they should...

That's not a reason to not use printf, just something that should be born in mind when doing so.

[Picuino]

One solution may be to store the message in a memory buffer and send it after passing through the point in the program that must be fast.

[free_electron]

One solution may be to store the message in a memory buffer and send it after passing through the point in the program that must be fast.

That in itself takes time. And your 'exception handling code' modifies the processor state. You are doing things that in the real application will not be done.
That's why you use an ICE or TRACE. They are non intrusive , the processor does not know they are there.
Many modern processors (Arm , Risc-V, QoriQ, MPC5xx , colfire, Tricore, xtensa, ARC)  have ETM and PTM (embedded trace macrocell and program trace macrocell. ).
You set those up and the entire processor state , including all registers , cache is cloned in once clockcycle. they use a ring buffer. so yo can see what happened BEFORE the event. it's like a digital scope : you can see before the trigger.

something as simple as a cortex-m3 already has ETM and it can run over the SWD

[PlainName]

One solution may be to store the message in a memory buffer and send it after passing through the point in the program that must be fast.

Your logging routine would likely be in a separate task, so the output would be buffered anyway. But there is a limit to buffer size and the chances are it's going to fill up and cause a tailback regardless.

[DiTBho]

Complex programs have complex interactions and state history, which absolutely requires built-in instrumentation and logging

With AI-driven ICEs, you still need instrumentation, but the ICE itself provides logging through its channels and memory (up to 256Mbyte on-board at the moment) for the state history and misc.

Researching area, but the new line also comes with optical SC/LC link from the TAP back end to the host, which makes it super-fast and Gibson-ish-Cyberpunk

[Mechatrommer]

One solution may be to store the message in a memory buffer and send it after passing through the point in the program that must be fast.

less atomic codes is less preferable i can see that now why printf is opened to debate. thats why i still prefer the simple code earlier, at best 1 cycle is needed to buffer an 8 bit register value... 2 or 3 cycles to figure out if fault has occured and trigger program halt and spitting binaries on the GPIO. KISS... buffering integer or long or double data type will need extra carefull attention esp when ISR is running.. buffering nice and charming "message" for the programmer's view is moot for me... imho the idea of debugging is to pinpoint at which part of the code thats misbehaving, or unexpected input / ISR intrusion has occured, not simply to capture the whole line of registers values, and certainly not restricting ourselves to use certain capable mcu such as JTAG/SWD feature i cant imagine how people who depend their life on JTAG alone program avr tiny (or even mega) line of mcu. no doubt jtag is charming as explained, i'm sure use it when i got to work in those line of mcus, and when its suitable/easier to do so compared to other strategies at hand.

[PlainName]

who depend their life on JTAG alone program avr tiny

Even the tiny has ICE nowadays

Doesn't help if you can't get 'em, of course

[Mechatrommer]

yup i dont have ice the hardware.. only a cloned isp mk2 if it can tells me where a recent interrupt routine.. interrupted my code (at machine/assembly/c level), maybe i should put some effort to get one?

[SiliconWizard]

There is no single, silver-bullet way of doing things.

Some bugs will only require simple logging to pinpoint, some trickier ones will require more complex code instrumentation based on your observations of the symptoms, and possibly several iterations of the instrumentation as you move forward.

Ways to debug time-critical parts of the code and non-time critical ones are also often different.

For non-time-critical stuff, and in particular when it doesn't directly interact with hardware (or that you can easily "mock" said hardware), this piece of code can be compiled on another platform such as a desktop computer and be tested/debugged there, which is much more comfortable and productive than trying to do it directly on a small embedded target.

Any part of code that is not directly using specific hardware and that has no timing requirements, I write it as portable as I can, and when it's complex enough that it would require serious testing (like some tricky algorithm), I do prototype it and test it on a desktop computer first before adding it to the embedded target's code base.

A small example: if you're implementing an ad-hoc, non-standard sorting algorithm that will run on a MCU, doing that with a desktop computer first is a very good idea and usually what I do. Once testing shows it's solid, you can use the code on your final target and as long as it's portable, there is usually no further debugging needed.

[Siwastaja]

The time it takes to collect and send out the contents , the data may have changed so you never see what is there at the moment of the trigger.

This is an important thing to bear in mind with printf (and similar) solutions: the act of printing can affect the timing of tasks and introduce an artificial speed constraint. Satisfied with your product you remove the debug stuff and suddenly things aren't happening as they should...

That's not a reason to not use printf, just something that should be born in mind when doing so.

That's the reason to bake relevant safety and instrumentation into the code from day one. Take it into account. Leave margin for logging, understand the consequences of logging.

Debugger might not add CPU instruction cycles, but if it traces variables it sure causes memory and bus cycles with equivalent delays affecting both CPU and DMA, with the difference that now you don't know where the delays exactly are, or might not even know them existing, as evidenced in this thread again.

[Siwastaja]

Some bugs will only require simple logging to pinpoint, some trickier ones will require more complex code instrumentation based on your observations of the symptoms, and possibly several iterations of the instrumentation as you move forward.

Yes! But even quite low-effort instrumentation done from day one tends to give very valuable hints about where the problem is, this is specifically useful when the bug happens in production and you can't reproduce it no matter what. If, thanks to instrumentation, you get to know it's within one particular piece of one module, you may be able to cope with just reading and re-reading that code again, unit testing that piece of code, or even just rewriting it.

I generally suggest going for low-hanging fruits and "neat tricks". At least half-decent modularity combined with argument validity checks and all assumptions you feel even a bit unsure of asserted is a very good start.

And +1 to "test hardware-independent code on PC". Hardware-dependent, that's usually tricky to breakpoint/single-step or variable-trace with a debugger because it involves exact timing and nasty footguns like reading a register having side effects, so you are left with custom instrumentation anyway (which doesn't need to be difficult even if "instrumentation" sounds fancy).

Also, beware of premature optimization. Don't use "it hogs CPU resources" as an excuse, when the real reason is laziness. Logging a few important variables is a few CPU clock cycles. You don't need to do it as the first operation of the 10MHz BW current sense comparator overcurrent ISR, you don't need to do it in the inner loop of a DSP operation. Everywhere else, a few cycles very well spent. printf() itself is obviously too slow to call randomly everywhere.

[SiliconWizard]

Regarding assumptions, the safest way of dealing with them is... you guessed it... not to make any.
So wherever you expect a specific range of values for the code to run properly - just check the values.
Only if this checking would make the code fail to meet timing requirements, could you consider removing the tests and making sure of the ranges by thorough testing and static analysis, but I suggest removing the tests only as a last resort.

As to asserts that have no effect on release code, see the quote I put in an earlier post.

[Siwastaja]

By assumptions, I mean we all make them. Otherwise we would write perfectly generic code which would solve all the problems in the Universe. But real code has built-in assumptions such as number_of_samples needs to be an even number, because that's obvious to anyone who understands the particular algorithm, right? But still, maybe your configuration bus corrupts a value every now and then. Or someone does not understand the algorithm. Or you realize down the road that odd number_of_samples would make sense after all and forgot about the hidden assumption. Make it explicit by assert(), because the other option would be to write another algorithm for odd values which could take too much design time. But an error check is way cheaper!

Make this a habit:

 instead of / in addition to:
// n_samples must be even
write:
assert(n_samples % 2 == 0);

And of course,
assert(n_samples >= 0 && n_samples <= NUM_ELEMS(sample_tbl)); // where #define NUM_ELEMS(arr) (sizeof((arr))/sizeof((arr)[0]))

[Nominal Animal]

No tool beats understanding the difference between developer intent and what the code actually does.

There are tons of different tools that can help you with that; the exact set best for the task depends on the developer and project at hand.

The worst case is when the developer culture is of the "throw it at the wall, and use that which sticks; you don't need to understand how or why it works as long as it looks like it might work" kind, and you support that by getting them the top-of-the-line debugging environments and tools.  You don't get any better code, you just get code that breaks in more inventive ways.

Just like security, debugging is something you need a human to do.  Tools can make that easier, but if the human uses the tools to "do the debugging work for them" (instead of describing what is happening and how; the why is human stuff), the end result tends to be shoddy shit the world is already full of.  I repeat, the most important tool in debugging is your own understanding, especially discovering and understanding the difference between the intent of the code and what the code actually does.

For example, many developers have difficulty noticing = instead of == (in code written by others; it is very human to not notice such typos in ones own output).  I, too, often miss those when I read the code to understand the intent.  However, when I do understand the intent of the code, I can re-read the code, and compare the intent to what the code actually does; like a hostile prosecutor of sorts, if you will.  Then, such bugs are surprisingly easy to notice.  The hardest part is switching between the two "modes", understanding the intent, and comparing the code against the intent, because a lot of code has more than one "intent": one is an immediate intent for the current block, but there may be other more general intents, like doing things a specific way to avoid having to do something undesired.  Sadly, usually those intents are not documented at all, and are only discovered when discussing the code amongst developers.  For my own code, I do need to sleep between writing it and analyzing it this way, or I won't "see" my own bugs at all.

[DiTBho]

Debugger might not add CPU instruction cycles, but if it traces variables it sure causes memory and bus cycles with equivalent delays affecting both CPU and DMA, with the difference that now you don't know where the delays exactly are, or might not even know them existing, as evidenced in this thread again.

Yup: two solutions for this
1) forcing the whole system into equivalent time, so the debugger will appear "no intrusive" (not a solution, it's rather a work-around)
2) don't use the ICE to measure time-sensitive things, use the performance analyzer, which is equal to measuring the time lapse between a rising and falling edges of a GPIO

[DiTBho]

debugging is something you need a human to do

Sure, A.I.ICEs don't understand humans. Some humans understand A.I.ICEs, but, until the strong-AI singularity (in the far far future ... 2060? 2070? 2100?), humans are the smartest things on Earth.

Don't hire an A.I.ICEs to debug humans things. It won't work.

A.I.ICEs are simply more expensive tools but also useful when they can better and faster identify common human behavioral patterns, hence common human bugs.

And don't let an A.I. (or RADs) code your programs for you. It won't work.

[Mechatrommer]

And don't let an A.I. (or RADs) code your programs for you. It won't work.

it can, only if it can understand when we convey our message to it verbally. or if it can read our mind. but then...

until the strong-AI singularity? (in the far far future ... 2060? 2070? 2100?), humans are the smartest things on Earth.

according to Einstein's postulate, it would be impossible (if i understand it correctly)...

You can't solve a problem with the ways of thinking that created it

expecting machine to do human's job will make the human is lesser than the machine, i think...

assuming certain "semantic" is/will be of infinite ambiguities/possibilities... you can put enough database into an expert system at current time, but when new problems raised in the future, you need to update the database otherwise the AI will be rendered obsolete. human is smartest, but doesnt mean free of errors or dumbless. how can human make a perfect machine if they themselves dont understand what they are made of, esp spiritually, or in the soul's world... if you understand, then you understand, if not, then i can understand why you dont

[Nominal Animal]

debugging is something you need a human to do

Sure, A.I.ICEs don't understand humans.

Rather, programming languages are still the best tool we have for conveying human intent to nonhuman processors.

If we had anything better to convey the intent, then we could write a compiler that generated code that we intended, instead of code that we wrote.  But we don't, so we can't.

It would be supremely funny to have debuggers that understand human intent better than a compiler.

(While I don't like code generators, they are still extremely useful for cases where the solution has an exact mathematical/computer-understandable description.)

[DiTBho]

If we had anything better to convey the intent, then we could write a compiler that generated code that we intended, instead of code that we wrote.  But we don't, so we can't.

It would be supremely funny to have debuggers that understand human intent better than a compiler.

(While I don't like code generators, they are still extremely useful for cases where the solution has an exact mathematical/computer-understandable description.)

It sounds "Pro-Logic", old 90s articles on the Byte-magazine 

Some inspired all the computers we see in Star Trek, pure science fiction, but full of passion and hope for a distant future.

Like the movie "BackToTheFuture part2": the movie predicted that in 2017 we should have flying cars ... have you seen any? ... 2021? 2022? OK, Google/LA (USA) has "self-driving cars" but nothing that can fly, and it's still clear if there is a quantum gravity ("graviton"? which ... !O!M!G! the name is already taken by Marvel for one of their superhero, I am afraid we need to choose a better name to avoid to be quoted in a court case), we still talk about an hypothetical quantum of gravity, an elementary particle that mediates the force of gravitational interaction (which is not a true force, but rather an effect of a potential field), so, I think we won't see any flying skate-boards for a long while ...

... except something similar (exploiting electromagnetic fields rather than anti gravity) on Youtube, thanks to HackSmithIndustry 

See
See