Debugging: Am I a dreamer. . . ?

Were you too busy talking to your girlfriend when the professor was talking about jtag debugging, single wire debugging on many micros such as AVR, ARM, etc.

No I was writing love letters to you... I wish you'd reply why have you gone all cold on me all of a sudden?

Because this is USENET, where folks get away with being rude.

And read the section of the data sheet titled "In Circuit Debugger".

Many chips have in-circuit debugging features, including that one. Read the fine manual. Few require the chip-and-socket approach -- that's more of an 80's/90's thing.

For some applications you'll find that reserving a pin (or pins) for debugging that you can twiddle with in software instead of a printf is more valuable than gold. Given an oscilloscope, not only will it tell you _that_ your code executes, but if you're careful it'll tell you when and for how long.

If you really programming in C for years, you know that using printf or debugger to remove bugs, only gives the design more bugs. Embedded solutions stay away bugs by careful design (in both IC/HW/BSP/SW).

That means the debugger version has a FSM running to implement a SW debugger! A 20b dollars's NRE cost may give you the solution. You need a SW stub, or an ICE stub.

In message , linnix writes

However what he accurately described is the bond-out-chip as used by emulators, not debuggers.

You can't beet an ICE for debugging. Jtag just don't really cut it.

Rip-van-winkle ?

Yup, that could work, only now you have TWO different die, and the one you debug with, is not the one you ship...... Spot the problem here ?.

Imagine that sub $1 part, with a built-in debug channel, so you can plug into the USB on the PC, and single step, view registers, etc ? Now, you debug using the silicon you ship. That's smart.

Wait! - someone already has this, and for under $20! Pick any off this list

I wasn't going to mention that as it usually causes a bun fight bit since you have...

You should never debug using printf.

This is why there are simulators, debuggers and Emulators. Even for PC's I can recall Borland had a system where you could debug one PC from another. For embedded using printf should have dies out over a decade ago.

In message , Tomás Ó hÉilidhe writes

It is called a bond out chip.

Used by Emulator manufacturers. Been around years

There are also chips with Jtag and or BDM or Nuxus or ...

I am some what worried if you have been programming a decade and don't know about any of this.

BTW do NOT debug with printf

What's wrong with debugging using printf? I don't mean specifically "printf", which you should normally avoid in a small embedded system, but the general idea of putting out extra information while the program runs is a very useful debugging technique. Simulators, debuggers, and emulators are all important for development and debugging, but sometimes it is easier to send out signals to show what is happening. Of course such things involve changes to your code, and changes to the run-time characteristics of your system - but that's often perfectly acceptable during development and debugging. It is not a good idea to rely on printf-style debugging as your *only* method of debugging - but equally it is a waste to arbitrarily exclude it from your toolbox.

Well you have answered the question.

Yes but not the same as using printf.

I have not found that to be the case but then I usually have a simulator, debugger or ICE to hand.

Which is why I don't like it. That said some debuggers instrument the code and some distort the time element.

I agree. For testing some code it can be useful... This is often for things like Unit Test where you wrap the function(s) under test in a test harness that can have printf or equivalents.

I think we agree.

Thanks for the replies.

So can anyone recommend a way of debugging a program on a PIC16F684? Please use full words instead of using initialisms; for instance I haven't got a clue what an ICE is or what it stands for.

Do I necessarily have to reserve certain pins on the chip for debugging? That would be a bad thing because I need all the pins in my current project.

In message , Tomás Ó hÉilidhe writes

Then you probably should not be doing embedded programming. Trey google with "ICE" and "embedded"

In-Circuit-Emulator. This is the main debugging tool for embedded work where there is no JTAG or BDM.

See

or even

where Microchip have information on the various ICE (their word) they do for their own parts.

Then the only option would be an ICE.

JTAG stands for Jesus, Theresa And God, and of course BDM stands for the Blessed Virgin Mary. You need all the help you can get when you're debugging.

JS

Amen :-)

Btw who is Theresa? The only one I knew had nothing to do with god... more the other side :-)

My general rule is: do not use printf() for debugging if you do not use it in the normal embedded application (Not all embedded systems are bare bones, no display systems.) That said I usually do not use printf() at the point of going to real hardware. by then you should have unit tested to the point that you KNOW there are no unhandled failure points. (You have to KNOW this if you are developing any medical device.)

I have worked on several systems where circuitry for a single output register controlling a set of LEDs has proven VERY useful. I was always amazed how much information I could get just watching the LEDs flashing (sometimes even displaying 2things at once).

Ed

In message , Simon Clubley writes

Printf mainly.

The serial port is used by various debug systems. Monitors and some RTOS.

Exactly.

Fair enough. I assume this code is shipped in the release?

Where you need to ship release, not debug, code you can't beat an ICE for full speed non intrusive debugging. They have many features you just can't do with a serial port.

You really are very unbright. You're saying that if someone doesn't know about something then they shouldn't try to learn about it. Quite the scholar there.

Thanks for the links.

A bun fight sounds fun!

Nothing. It works fine for me. I'm also a fan of the "toggling port pins" method of debugging.

I agree 100%. Many of the embedded systems I've worked on have diagnostic headers which are connected to serial ports. Having status information being "printed" on those ports when significant events happen can be extremely useful. You do have to pay attention to the timing implications...