Debugging: Am I a dreamer. . . ?

I've been programming in C for the best part of a decade now but it's
only within the last year that I've really started doing embedded
systems programming.

When I did C programming for a personal computer, I commonly debugged
my code simply by putting in printf statements around the place to
check variable values, and also by using the instrument that lets you
check the values of variables at runtime when you're stepping through
the code.

Anyway, when I was doing my embedded systems project this year for
college, I was kind of in the dark when my board's program started to
malfunction. If I'd been using a PC, I would have used the debugger to
single-step through code to check variables' values. What I eventually
did was take the offending code and move it across to a PC, and then I
used the PC to debug it.

Anyway, here's the dream I had in my head, which may or may not be a
pipe dream:
   You know the PIC16F684 chip that costs less than a dollar, well
what if they brought out the debug version of it (that costs maybe 20
dollars). The debug version would fit perfectly into the normal chip
slot, except that it would have some sort of socket on the top of it
for hooking it to a PC for doing stuff like printf's, and also maybe
for running a full debugger that will let you check variables' values?

> Anyway, when I was doing my embedded systems project this year for
> college, I was kind of in the dark when my board's program started to
> malfunction.

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.

On Apr 30, 1:08=A0am, linnix <m...@linnix.info-for.us> wrote:
> > Anyway, when I was doing my embedded systems project this year for
> > college, I was kind of in the dark when my board's program started to
> > malfunction.
>
> 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?

On Tue, 29 Apr 2008 17:50:19 -0700, Tomás Ó hÉilidhe wrote:

> On Apr 30, 1:08&nbsp;am, linnix <m...@linnix.info-for.us> wrote:
>> > Anyway, when I was doing my embedded systems project this year for
>> > college, I was kind of in the dark when my board's program started to
>> > malfunction.
>>
>> 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".

-- 
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

On Tue, 29 Apr 2008 16:45:34 -0700, Tomás Ó hÉilidhe wrote:

> I've been programming in C for the best part of a decade now but it's
> only within the last year that I've really started doing embedded
> systems programming.
> 
> When I did C programming for a personal computer, I commonly debugged my
> code simply by putting in printf statements around the place to check
> variable values, and also by using the instrument that lets you check
> the values of variables at runtime when you're stepping through the
> code.
> 
> Anyway, when I was doing my embedded systems project this year for
> college, I was kind of in the dark when my board's program started to
> malfunction. If I'd been using a PC, I would have used the debugger to
> single-step through code to check variables' values. What I eventually
> did was take the offending code and move it across to a PC, and then I
> used the PC to debug it.
> 
> Anyway, here's the dream I had in my head, which may or may not be a
> pipe dream:
>    You know the PIC16F684 chip that costs less than a dollar, well
> what if they brought out the debug version of it (that costs maybe 20
> dollars). The debug version would fit perfectly into the normal chip
> slot, except that it would have some sort of socket on the top of it for
> hooking it to a PC for doing stuff like printf's, and also maybe for
> running a full debugger that will let you check variables' values?

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.

-- 
Tim Wescott
Control systems and communications consulting
http://www.wescottdesign.com

Need to learn how to apply control theory in your embedded system?
"Applied Control Theory for Embedded Systems" by Tim Wescott
Elsevier/Newnes, http://www.wescottdesign.com/actfes/actfes.html

Tom&aacute;s &Oacute; h&Eacute;ilidhe <toe@lavabit.com> writes:

> I've been programming in C for the best part of a decade now but it's
> only within the last year that I've really started doing embedded
> systems programming.
>
> When I did C programming for a personal computer, I commonly debugged
> my code simply by putting in printf statements around the place to
> check variable values, and also by using the instrument that lets you
> check the values of variables at runtime when you're stepping through
> the code.
>

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

> Anyway, when I was doing my embedded systems project this year for
> college, I was kind of in the dark when my board's program started to
> malfunction. If I'd been using a PC, I would have used the debugger to
> single-step through code to check variables' values. What I eventually
> did was take the offending code and move it across to a PC, and then I
> used the PC to debug it.
>
> Anyway, here's the dream I had in my head, which may or may not be a
> pipe dream:
>    You know the PIC16F684 chip that costs less than a dollar, well
> what if they brought out the debug version of it (that costs maybe 20
> dollars). The debug version would fit perfectly into the normal chip
> slot, except that it would have some sort of socket on the top of it
> for hooking it to a PC for doing stuff like printf's, and also maybe
> for running a full debugger that will let you check variables' values?
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 
<bc847474-9598-4012-a4f5-003093a0accd@v23g2000pro.googlegroups.com>, 
linnix <me@linnix.info-for.us> writes
>
>> Anyway, when I was doing my embedded systems project this year for
>> college, I was kind of in the dark when my board's program started to
>> malfunction.
>
>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.
>

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.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Tom�s � h�ilidhe wrote:
> Anyway, here's the dream I had in my head, which may or may not be a
> pipe dream:

Rip-van-winkle ?

>    You know the PIC16F684 chip that costs less than a dollar, well
> what if they brought out the debug version of it (that costs maybe 20
> dollars). The debug version would fit perfectly into the normal chip
> slot, except that it would have some sort of socket on the top of it
> for hooking it to a PC for doing stuff like printf's, and also maybe
> for running a full debugger that will let you check variables' values?

  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

http://www2.silabs.com/tgwWebApp/public/web_content/products/Microcontrollers/en/USBToolStick.htm

In message <m1d4o7remo.fsf@gmail.com>, Hao Wang <doitmy@gmail.com> 
writes
>Tom&#4294967295;s &#4294967295; h&#4294967295;ilidhe <toe@lavabit.com> writes:
>
>> I've been programming in C for the best part of a decade now but it's
>> only within the last year that I've really started doing embedded
>> systems programming.
>>
>> When I did C programming for a personal computer, I commonly debugged
>> my code simply by putting in printf statements around the place to
>> check variable values, and also by using the instrument that lets you
>> check the values of variables at runtime when you're stepping through
>> the code.
>>
>
>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).

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.

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In message 
<75be5b80-caad-47ad-8a30-2eacff72abe5@r66g2000hsg.googlegroups.com>, 
Tom&#4294967295;s &#4294967295; h&#4294967295;ilidhe <toe@lavabit.com> writes
>
>I've been programming in C for the best part of a decade now but it's
>only within the last year that I've really started doing embedded
>systems programming.
>
>When I did C programming for a personal computer, I commonly debugged
>my code simply by putting in printf statements around the place to
>check variable values, and also by using the instrument that lets you
>check the values of variables at runtime when you're stepping through
>the code.
>
>Anyway, when I was doing my embedded systems project this year for
>college, I was kind of in the dark when my board's program started to
>malfunction. If I'd been using a PC, I would have used the debugger to
>single-step through code to check variables' values. What I eventually
>did was take the offending code and move it across to a PC, and then I
>used the PC to debug it.
>
>Anyway, here's the dream I had in my head, which may or may not be a
>pipe dream:
>   You know the PIC16F684 chip that costs less than a dollar, well
>what if they brought out the debug version of it (that costs maybe 20
>dollars). The debug version would fit perfectly into the normal chip
>slot, except that it would have some sort of socket on the top of it
>for hooking it to a PC for doing stuff like printf's, and also maybe
>for running a full debugger that will let you check variables' values?


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

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/