Debugging: Am I a dreamer. . . ?

On Apr 30, 10:43 am, Grant Edwards <gra...@visi.com> wrote:
> On 2008-04-30, Chris H <ch...@phaedsys.org> wrote:
>
> >>I've got a real-time state-machine problem I'm trying to fix
> >>right now and if I could get a timestamped trace of writes to a
> >>couple addresses, it probably would have been fixed a week ago.
> >>:/
>
> > You need an ICE :-)
>
> I know. :)
>
> > What is the MCU?
>
> Texas Instruments MSP430F2330
>
> >>But, none of the parts I've ever used supported anything other
> >>than the basic "halt the processor and examine the state" JTAG
> >>interfaces.  Maybe I'm just not spending enough money on
> >>processors.
>
> > What is the processor. AFAIK there are Ice for PIC, and 51 up.
> > It is the bigger parts that don't have ICE.
>
> The parts I've used recently are ARM (Samsung), H8, AVR, and
> MSP430.  All are plain JTAG except the H8 which I don't
> remember having any debugging support (except for a GDB stub
> that I ported to it).
>
> I think there might be real ICE for some AVR parts, but I
> haven't spent much time on that one yet.

Yes, there are Jtag Ice for some of the bigger AVR.  There are cool
when working; unfortunately, not always reliable.

>
> --
> Grant Edwards                   grante             Yow! Should I get locked
>                                   at               in the PRINCICAL'S
>                                visi.com            OFFICE today -- or have
>                                                    a VASECTOMY??

>On 2008-04-30, Chris H <chris@phaedsys.org> wrote:
>The parts I've used recently are ARM (Samsung), H8, AVR, and
>MSP430.  All are plain JTAG except the H8 which I don't
>remember having any debugging support (except for a GDB stub
>that I ported to it).
>
>I think there might be real ICE for some AVR parts, but I
>haven't spent much time on that one yet.
>
>-- 
>Grant Edwards   

Grant,

Full ICE is available for all the H8 (and almost all MCU) Renesas devices.
But, of course, it requires lots of money. Which makes the GDB stub (or
JTAG) the best bet for on-chip debug on the cheap.

--CG

On 2008-04-30, vinnie <ckgrier2@mailcan.com> wrote:
>>On 2008-04-30, Chris H <chris@phaedsys.org> wrote:
>>
>>The parts I've used recently are ARM (Samsung), H8, AVR, and
>>MSP430.  All are plain JTAG except the H8 which I don't
>>remember having any debugging support (except for a GDB stub
>>that I ported to it).
>>
>>I think there might be real ICE for some AVR parts, but I
>>haven't spent much time on that one yet.
>
> Full ICE is available for all the H8 (and almost all MCU)
> Renesas devices. But, of course, it requires lots of money.
> Which makes the GDB stub (or JTAG) the best bet for on-chip
> debug on the cheap.

I stand corrected. I guess I never needed it badly enough to
track down ICE for the H8 (and spend the money).  IIRC, the
last ICE I bought was for the M16C, and the price tag on that
was somewhere close to $10K.  That project got cancelled before
I even got the boxes unpacked...

-- 
Grant Edwards                   grante             Yow!  Yow! Are we in the
                                  at               perfect mood?
                               visi.com            

On Apr 30, 5:19 pm, Grant Edwards <gra...@visi.com> wrote:
> On 2008-04-30, Chris H <ch...@phaedsys.org> wrote:
>
> > In message <L9-dnZFHX8O064XVnZ2dnUVZ_o_inZ2d@visi>, Grant Edwards
> ><gra...@visi.com> writes
> >>On 2008-04-30, Chris H <ch...@phaedsys.org> wrote:
>
> >>> It is called a bond out chip.
>
> >>> Used by Emulator manufacturers.  Been around years
>
> >>And it's been extinct for years (none of the processors I've
> >>used in the past decade have had bond out parts or real
> >>in-circuit-emulators available.
>
> > Then you are looking an a small market.
>
> Obviously, since I doubt it's possible for anybody to use a
> significant portion of the parts on the market.
>
> > Many parts still have ICE.
>
> Right, but it sure seems to be getting pretty rare.
>
> >>> There are also chips with Jtag and or BDM or Nuxus or ...
>
> >>That's about as good as it gets these days.
>
> > Not exactly that is about to change.
>
> > If you like a Second generation JTAG+ Trace that is closer to
> > ICe functionality.
>
> At the last embedded systems conference I went to, a lot of
> vendors were flogging the JTAG-based trace stuff, and it sure
> would be nice.  I've got a real-time state-machine problem I'm
> trying to fix right now and if I could get a timestamped trace
> of writes to a couple addresses, it probably would have been
> fixed a week ago. :/
>
> But, none of the parts I've ever used supported anything other
> than the basic "halt the processor and examine the state" JTAG
> interfaces.  Maybe I'm just not spending enough money on
> processors.
>

I've worked on a arm7 design with etm, don't know if it ever got
build.
coprocessor 14 is a communication register you can read and
write via jtag without halting the processor.

with lots of embedded stuff not halting the processor can be a very
important feature, with comms that need to keep syncronization or
hardware run in closed loop it is often impossible to halt the
processor
without breaking something....

-Lasse

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?

It called the PIC16F684.  Just get the ICD2  $169 USD or an emulator for 
$2000
If you need a printf the PICs do have a serial port.  printf is kind of 
big so that that into account

Tom�s � h�ilidhe wrote:
> 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.
The ICE 2000 does not require you to loose any pins.  The ICD2 uses the 
same 3 to 4 pins as the programmer.

On 2008-04-30, Chris H <chris@phaedsys.org> wrote:
> In message <48184695$0$23852$8404b019@news.wineasy.se>, David Brown 
>>
>>What's wrong with debugging using printf?  I don't mean specifically 
>>"printf", which you should normally avoid in a small embedded system,
>
> Well you have answered the question.
>
>>but the general idea of putting out extra information while the program
>> runs is a very useful debugging technique.
>
> Yes but not the same as using printf.

One thing that often seems to get overlooked is assert().  It
shouldn't be because it is really your friend.  I've often seen
people using things like "printf("Value of n is %d\n", n)" when
all they are really worried about is that n always fulfils some
condition, whether it be never going negative, or exceeding a
certain value, or whatever.  That is precisely where assert() is
useful.

Having said this I have my own set of macros that I like to use
for things like this, primarily for hosted stuff.  They provide a
slightly more comprehensive and robust framework for these kinds
of diagnostic. ASAS_TAUT() is roughly equivalent to the standard
assert() and ASAS_CONT() is the same only with an inverted trigger
sense. 

The nearest to a printf equivalent is ASAS_DIAG(n, mesg) which is
non-fatal and prints mesg (to stderr) if n >= ASAS_DBG.  There is
also ASAS_NOTREACHED() and a few other macros for particular
situations.  They all have functionality on a par with the standard
assert() giving file and line number, but with a couple of extra
refinements.

Firstly the inclusion sense if the opposite to assert() in that
they expand to nothing unless ASAS_DBG is defined - in my book
assert() does this the wrong way around.  Also one particularly
neat trick is the trigger behaviour.  On x86 at least they don't
call _exit() or some other nonsense, they do an asm("int3").  In
a debugger they function as handy built in breakpoints that are
waiting to be triggered when needed.

-- 
Andrew Smallshaw
andrews@sdf.lonestar.org

On Apr 30, 12:30=EF=BF=BDpm, Tom=EF=BF=BDs =EF=BF=BD h=EF=BF=BDilidhe <t...@=
lavabit.com> wrote:
> 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.

You can often use a bigger version of the same chip with extra ports.