Debugging Techniques

Go To Last Post

26 posts / 0 new

Author

Message

fizgig

Level: Hangaround

Joined: Tue. May 3, 2005

Posts: 355 View posts

Location: Windsor, CA

Posted by fizgig: Fri. Apr 24, 2009 - 11:25 PM

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!

Tags:

AVR Microcontrollers, megaAVR and tinyAVR

Mike B

Level: Raving Lunatic

Joined: Tue. Jun 22, 2004

Posts: 3836 View posts

Location: South West Utah, USA

Posted by Mike B: Sat. Apr 25, 2009 - 12:06 AM

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

Simonetta

Level: Raving Lunatic

Joined: Wed. Mar 12, 2003

Posts: 3025 View posts

Location: Portland, Oregon USA

Posted by Simonetta: Sat. Apr 25, 2009 - 12:39 AM

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.

fizgig

Level: Hangaround

Joined: Tue. May 3, 2005

Posts: 355 View posts

Location: Windsor, CA

Posted by fizgig: Sat. Apr 25, 2009 - 06:13 AM

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

Level: Moderator

Joined: Wed. Mar 28, 2001

Posts: 29990 View posts

Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)

Posted by js: Sat. Apr 25, 2009 - 06:53 AM

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

victor_song

Level: New Member

Joined: Wed. Feb 25, 2009

Posts: 12 View posts

Posted by victor_song: Sat. Apr 25, 2009 - 06:54 AM

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

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101186 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

Posted by clawson: Sat. Apr 25, 2009 - 01:54 PM

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

ArnoldB

Level: Raving Lunatic

Joined: Thu. Nov 29, 2007

Posts: 3185 View posts

Posted by ArnoldB: Sat. Apr 25, 2009 - 03:43 PM

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.

dkinzer

Level: Posting Freak

Joined: Fri. Mar 12, 2004

Posts: 1299 View posts

Location: Portland, OR, USA

Posted by dkinzer: Sat. Apr 25, 2009 - 04:22 PM

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

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101186 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#10

Posted by clawson: Sat. Apr 25, 2009 - 04:24 PM

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)

Koshchi

Level: 10k+ Postman

Joined: Wed. Nov 17, 2004

Posts: 15658 View posts

Location: Vancouver, BC

#11

Posted by Koshchi: Sat. Apr 25, 2009 - 04:33 PM

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.

Level: Moderator

Joined: Wed. Mar 28, 2001

Posts: 29990 View posts

Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)

#12

Posted by js: Sat. Apr 25, 2009 - 10:23 PM

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

gr82bdad

Level: Hangaround

Joined: Fri. Jul 22, 2005

Posts: 287 View posts

Location: Lenexa, KS

#13

Posted by gr82bdad: Sun. Apr 26, 2009 - 01:53 AM

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

Guillem Planisi

Level: Raving Lunatic

Joined: Fri. Jun 11, 2004

Posts: 2405 View posts

Location: Vilanova (Barcelona)

#14

Posted by Guillem Planisi: Sun. Apr 26, 2009 - 09:00 AM

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.

JohanEkdahl

Level: 10k+ Postman

Joined: Wed. Mar 27, 2002

Posts: 26945 View posts

Location: Lund, Sweden

#15

Posted by JohanEkdahl: Sun. Apr 26, 2009 - 09:47 AM

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]

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3270 View posts

Location: Bratislava, Slovakia

#16

Posted by wek: Sun. Apr 26, 2009 - 10:07 AM

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

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

AndersAnd

Level: Posting Freak

Joined: Wed. Apr 23, 2003

Posts: 1120 View posts

Location: Denmark

#17

Posted by AndersAnd: Sun. Apr 26, 2009 - 11:11 AM

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

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101186 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#18

Posted by clawson: Sun. Apr 26, 2009 - 11:55 AM

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!

ArnoldB

Level: Raving Lunatic

Joined: Thu. Nov 29, 2007

Posts: 3185 View posts

#19

Posted by ArnoldB: Sun. Apr 26, 2009 - 12:24 PM

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.

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101186 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#20

Posted by clawson: Sun. Apr 26, 2009 - 12:35 PM

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!]

ifor

Level: Rookie

Joined: Tue. May 27, 2008

Posts: 41 View posts

#21

Posted by ifor: Sun. Apr 26, 2009 - 12:48 PM

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

AndersAnd

Level: Posting Freak

Joined: Wed. Apr 23, 2003

Posts: 1120 View posts

Location: Denmark

#22

Posted by AndersAnd: Sun. Apr 26, 2009 - 12:49 PM

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.

clawson

Level: Moderator

Joined: Mon. Jul 18, 2005

Posts: 101186 View posts

Location: (using avr-gcc in) Finchingfield, Essex, England

#23

Posted by clawson: Sun. Apr 26, 2009 - 01:06 PM

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.

wek

Level: Raving Lunatic

Joined: Fri. Dec 16, 2005

Posts: 3270 View posts

Location: Bratislava, Slovakia

#24

Posted by wek: Sun. Apr 26, 2009 - 02:14 PM

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

The real debugger is between the chair and the keyboard.

jayjay1974

Level: Raving Lunatic

Joined: Wed. Oct 30, 2002

Posts: 5763 View posts

Location: The Netherlands

#25

Posted by jayjay1974: Sun. Apr 26, 2009 - 02:19 PM

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 :(

stu_san

Level: Raving Lunatic

Joined: Fri. Dec 30, 2005

Posts: 2321 View posts

Location: Fort Collins, CO USA

#26

Posted by stu_san: Mon. Apr 27, 2009 - 05:21 PM

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!

Jump To

Search form

Debugging Techniques

Tags: