Debugging Techniques

Go To Last Post
26 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been doing a little c programming on AVRs through winavr and I'd like to learn more about what options there are to aid in debugging.

Often I'll realize I have no idea where in the program the chip is freezing. I also would like to know how variables are being updated during program execution. Setting break points and stepping line by line would be awesome.

I've dabbled a little with the Atmel toolset but most of my stuff is interfacing with other chips and I don't know how to do the interfacing so using a pure software emulator doesn't make sense for me - I'd rather be able to look right into a running chip instead.

I understand there are debugging tools and software but I haven't been able to find any posts/information that explains how this stuff works from the ground up - they all seem to think you already know most of the story.

Can anyone point me at an article or post that explains what options there are, what you can do with those options and so on? I think it's time that I invested time in learning some of this stuff.

Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVRTV - Debugging with JTAGICEmkII
http://www.avrtv.com/2008/09/25/...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Debugging is an art. Knowing where to stop the program and what to look for in variable values. Some people do it with LEDs on unused pins that flicker when the code gets to a certain place or a variable has a certain value.

Debugging is the main reason why I have resisted migrating to C language since the WinAVR became available. With assembler you are like an auto mechanic who is tightening the bolts and adjusting the carb by hand and feeling how the engine works. Debugging with C is like tuning an engine over the telephone. C is wonderful: it amplifies your productivity as a programmer: it is flexible, versatile, and portable. It is a real pain in the neck whenever the code doesn't work like it is supposed to and you have no idea as to why it isn't working.

Try getting an old Atmel ICE200 if you can find one. It is a real in-circuit emulator as opposed to a JTAG or DebugWire debugger that writes code into the flash and shortens the life of the device with each write cycle. The ICE200 emulated obsolete AVR devices but there are cross devices that match more or less the ICE200 targets. The Mega8/48/88 can be emulated by using the 90S8535 target, the Tiny13 using the 90S4434? target and so forth.

Even with using Warnier-Orr diagrams and careful walk-thoughs, I can go through several hundred test writes of a non-trivial section of code into an AVR device before everything is 'bulletproof'. Break your code into sections that are obvious and guaranteed-to-work, too-simple-to-fail. Get the sections working and then paste them together. Modularize: divide and overcome.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the comments. I'll go take a look at the link and look into the ICE200.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I'll go take a look at the link and look into the ICE200.
That's too old and possibly no longer available. It only supports a few older chips.

The Dragon is a cost effective debugger even if only with chips with 32K max of flash.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I suppose maybe it's a good way to spend some time on doing a tracing module with a uart for your project. After done, It can help you all the time.

victor song

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

The Dragon is a cost effective debugger even if only with chips with 32K max of flash.

Second vote for Dragon as an entry into OCD interfaes. If you hunt around a bit you'll find that someone's broken the artificial 32K limit anyway. The one thing you have to be wary of with the Dragon is its under-rated voltage regulator. Things to prevent damage include using a powered USB hub between PC and Dragon and insulating the regulator area of the Dragon PCB

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I find debugging is mostly an exercise in getting your thoughts in order plus some craftsmanship.


The fact that large parts of today's youth is hardly capable of concentrating on one thing for longer than a microsecond, having a coherent thought, and reading text longer than 160 characters, might well be the reason for many crappy software.

Debugging for me consists of the following procedure:

- Observe the symptoms of the failure

- Develop a theory what could go wrong in HW or SW that probably might result in the observed symptoms. This requires knowing your HW, SW, datasheet, compiler, programming language, etc.

- Think about a strategy, procedure, measurement setup, probing suitable to prove or disprove the theory you just developed. Devise an "experiment". This requires having a number of tools at your disposal, being familiar with them and being skilled in a number of techniques, meaning having a physical and mental toolbox available for doing the "experiment".

The experiment might be a "physical" experiment, measuring values with an oscilloscope or with a debugger or some other tool, or it might be executing parts of your program in your mind (or with pencil and paper).

- Do the experiment. Do one at a time. Random probing, hustle and bustle, whining/panic ("help, does not work, urgent1!!1!!") usually does not give useful results.

- Thoroughly evaluate the result(s) from the experiment. Meaning think, Think, THINK, and then THINK harder. Consider side effects. Could your experiment have changed the rules of the game, for example, could it have changed timing issues that might be relevant?

- If you still think your theory is right, adjust the experiment or devise another experiment and repeat

- If you have convinced yourself your theory is false make a new theory and repeat

- If you run out of theories, but the fsching thing still doesn't work, put it away, do something else. Go for a long walk, have a few drinks or whatever. Try again later.

- Futzing around rarely works. But if you had a few drinks you don't care any more.

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Simonetta wrote:
[C] is a real pain in the neck whenever the code doesn't work like it is supposed to and you have no idea as to why it isn't working.
Debugging C is fundamentally no more difficult than debugging assembly code. You have all of the same options available: observing I/O lines using a n oscilloscope or logic analyzer, using LEDs on I/O lines to convey state information, using "print statement" debugging techniques, and using an in-circuit debugger like JTAG Mk II.

The one difference that may initially be a stumbling block is mentally mapping the C code to the underlying assembly language code when using an in-circuit debugger. This, like most other skills, is a capability that can be acquired with some effort and practice. A mixed C/assembly language listing is very useful in this endeavor. How you might get such a listing depends on the particulars of your compiler. With the WinAVR compiler, it is quite simple to modify the makefile to generate a .lss file which contains interleaved C/assembly language. Of course, the compiler optimizations sometimes make this difficult to follow but that, too, is an acquired skill.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

A mixed C/assembly language listing is very useful in this endeavor. How you might get such a listing depends on the particulars of your compiler

If using Studio as the debugger then the easiest answer is to have IT produce the interleaved C/Asm view for your (though it's sometimes not quite as accurate as the .lss)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Debugging C is fundamentally no more difficult than debugging assembly code.

I disagree. C is far easier to debug than assembly, especially nowadays with modern IDEs. With assembly you have to know where a variable is stored and how it is interpreted. With C you can usually just hover the cursor over the variable to see its current value in the format that it represents.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

...I won't get into that...I won't get into that......I won't get into that......I won't get into that......I won't get into that......I won't get into that......I won't get into that......I won't get into that......I won't get into that......I won't get into that...

I must not......aaaarrrrgggghhhh

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Start with a Dragon and AVR studio. My JTAGICE MKII has been gathering dust since I got a couple of dragons. Debug wire is very handy.

One feature I use a bunch is to set a break point that occurs about once a second somewhere and then select "Continue execution after updating windows." Then, you can watch all your variables - by name - in near real time.

This is great for calculations and formulas, but not good for time critical stuff.

Also, if you're starting with some imported code, you need to study it for a long while and understand it fully. Building a successfully compiled project with 3rd party code without a thorough understanding of it is asking for hours of head scratching debugging time.

official AVR Consultant
www.veruslogic.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Master Lawson: does -O0 optimization setting produce a more lineal ASM <--> C correspondence (with a lot of code bloating) that eases the C debugging with WinAVR since one can check Samperis, sorry, ASM much better?

ArnoldB had done a magnificent explanation about the debugging process. And this explanation shows that while JTAG is a damn good tool, many other ('scopes, logic probes, LED's) tools may be the way to go. The bigger the toolset and debug options, easier and faster one can find the problem.

Remember that finding the problem is more than half way to solve it.

Guillem.
"Common sense is the least common of the senses" Anonymous.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ArnoldB's descrition of debugging through hypothesis testing is excellent, and (I suppose) what any seasoned programmer knows explicitely or intuitively. Let me just add that another principle to obey is the "divide and conquer" methodology. This involves eg cutting off things that definitively will not have anything to do with the problem, or writing "dummy replacements" for things so that you have some well defined behaviour, cutting down code to the smallest possible chunk that still displays the problem etc etc.


The fact that large parts of today's youth is hardly capable of concentrating on one thing for longer than a microsecond, but still wants to write all the code at once, might well be the reason for many cries for help here.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The must-read of debugging:
http://cm.bell-labs.com/cm/cs/tp...

JW

(PS. This one might be inspirative, too... ;-) )

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So how does JTAGICE mkII compare to Dragon as a debugger?
The Dargon documentation talks about emulating AVRs for debugging: http://support.atmel.no/knowledg...
Does this mean the Dragon only emulate AVRs istead of real on-chip debugging?

clawson wrote:
Quote:

The Dragon is a cost effective debugger even if only with chips with 32K max of flash.

Second vote for Dragon as an entry into OCD interfaes. If you hunt around a bit you'll find that someone's broken the artificial 32K limit anyway.

Link to Dragon 32 kB limit hack: https://www.avrfreaks.net/index.p...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In operation there's no obvious difference between using a JTAGICEmkII and a Dragon. They both do both JTAG and debugWire.

"in circuit emulator" or "in circuit emulation" is a misnomer. Back in the day Atmel produced devices called ICE40/ICE50/ICE200 (I've got an ICE50 in a box somewhere that's never used any more) which was a bunch of controlled/observable logic gates that really did emulate an AVR core and the header from the device plugged into the target AVR socket and apparently worked as if the real chip was in place. This is a true emulator. This was required (for mega8 in our case) because the early AVRs didn't have JTAG or dW

The "ICE" tag carried over to JTAGICEmkII and then Dragon but these are NOT emulators. They are boundary scan interfaces that simply watch/control what's going on inside the real silicon which effectively has the "ICE" built in using their OCD interfaces. The Dragon and the JTAGICEmkII are no different from one another in this respect.

Cliff

PS You can see pictures of ICE40/50/200 in Studio help - they are immense great things!

PPS of course one advantage the true ICEs have over OCD interfaces is that they have an execution trace buffer so you can see where the AVR has been when it reaches the crash!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Let me just add that another principle to obey is the "divide and conquer" methodology
Divide and conquer - don't leave the house without it.

It is one of the very few universal engineering methods, particular in software. Otherwise software, after decades of (often pseudo) research into "software engineering", still lacks horrible in the engineering method department.

JohanEkdahl wrote:
This involves eg cutting off things that definitively will not have anything to do with the problem, or writing "dummy replacements" for things so that you have some well defined behaviour, cutting down code to the smallest possible chunk that still displays the problem etc etc.
You can subsume that under the devise a theory / perform an experiment / evaluate the result, too. Determining what could not cause the problem is the theory part. Cutting it out and running the resulting software is the experiment.

JohanEkdahl wrote:

In short, youth sucks :-)

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

In short, youth sucks

To my mind it's something wrong with the education system if they are being taught a "I want everything on a plate right now" mentality.

[N dnt gt mi strtd abt th aboos uv Nglitch thy sem 2 B tort thees dys!]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I seldom use my dragon for debuging although I have on occasions. I prefer the older methods. I like to get printf working either to a uart or to an SD card logfile where posible. If the cost of printf is too much I have a seperate small board with an lcd with code that just listens to the uart and a simple protocol to alow my project code to send information to this to be displayed on the lcd. The cost is one pin and very little code. I like to have an led avalible if needed and have been known to put a scope on this to check thing like interrupt code execution times.

Ifor

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the clarification.
So in reality they are both In-Circuit Debuggers (IDC) rather than In-Circuit Emulators (ICE).
Maybe they should have named it JTAGICD instead of JTAGICE, but JTAGICE is much easier to pronounce than JTAGICD.
Microchip calls their PIC In-Circuit-Debugger for MPLAB ICD 2 (In-Circuit Debugger/Programmer).

So the only reason to spend 6 times as much for JTAGICE mkII compared to Dragon is to get rid of the 32 kB debugging limit and get a nice plastic enclosure?

I guess real In-Circuit Emulators (ICE) use an FPGA to emulate the various MCUs.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

in reality they both In-Circuit Debuggers

Well Atmel's phrase is OCD=On Chip Debug, but "yes"
Quote:

So the only reason to spend 6 times as much for JTAGICE mkII compared to Dragon is to get rid of the 32 kB debugging limit and get a nice plastic enclosure?

Yup, that's about the size of it - but in a commercial environment that added robustness is worth it's weight in gold (and definitely worth +$250). The one "fragile" bit of the JTAGICEmkII is just the zebra strip.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ICE, ICD, monitors, simulators, printf, blinking LED... that's all just tools.

The real debugger is between the chair and the keyboard.

JW

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In a commercial environment where an engineer can cost per hour as much as a Dragon nobody wants to mess around with soldering wires onto a bare PCB and making enclosures etc, it much more economical to buy a JTAGICE that works right out of the box (and usually keeps on working and does not die if you touch it...)

The flat foil connector is indeed a bit weak, and replacements are not cheap :(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Quote:

In short, youth sucks

To my mind it's something wrong with the education system if they are being taught a "I want everything on a plate right now" mentality.
*Sigh* :roll: When did I become the old f**t that I hated as a youngster?

I argue that every generation, when they get experienced, forget what it is like to face the unknown. Which pundit was it that said, "Youth is wasted on the young"?

While I agree there are those (in every generation) who want their world on a silver platter, I believe most people realize that programming is part science, part art, and that they need to work at learning it.

We, as the older generation, need to develop both tolerance for the repetitive questions and a way to discern the lazy slobs from the earnest learners. Both are out there, but our crime is when we lump all newbies into one category.

I also heard once that, "If a field describes itself as a 'science', you can be sure it is not a science". Political Science. Economic Science. Computer Science. HMMm...

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!