Searching \ for '[PIC]: difference between ICD and serial debugging' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=icd
Search entire site for: 'difference between ICD and serial debugging'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: difference between ICD and serial debugging'
2006\05\12@140834 by Stef Mientki

flavicon
face
I'm not familiar with ICD debugging,
and can't find this information on Microchip's site.

To me the ICD debugging technique looks almost identical to so called
serial debugging.
As most of my designs already have a serial RS232 (or USB) connection,
I think it would be as good as ICD,
or even better, because you don't spoil any extra pins.

So what's the real advantage of ICD over RS232 ?

thanks,
Stef Mientki

2006\05\12@141844 by Maarten Hofman

face picon face
Rochester, 12 mei 2006.

Not that I ever used ICD, but if I type ICD and Microchip in google, I get
www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en010046
as
my first link, which tells me that ICD allows you to step through the code
running on your PICmicro, and set break points and read register values and
such. Now I'm not sure about your RS232 or USB connections, but I believe
the best you can do with those is have your code send information to a
display window now and then, so basically it is debugging à la "printf()"
instead of using breakpoints and register dumps and stack backtraces...

Greetings,
Maarten Hofman.

2006\05\12@142355 by Mike Hord

picon face
Breakpoints.  The ability to monitor registers and change their values
on the fly.  Single stepping through code.  The ability to alter the
PC to begin execution of the code at a specific location.  The fact
that you don't need to use the serial port for it, so you can debug a
serial application with it (it DOES cost two pins, but those are two
of the least painful pins to lose, since they have relatively few
peripherals associated with them).  The ability to do a hardware
reset.

FAR more powerful than serial debugging.  FAR FAR FAR more powerful.

Mike H.

On 5/12/06, Stef Mientki <spam_OUTs.mientkiTakeThisOuTspammailbox.kun.nl> wrote:
{Quote hidden}

> -

2006\05\12@151317 by Stef Mientki

flavicon
face
thanks Mike,

but ...
... a lot of (may all) things you mentioned, can be done through serial

Mike Hord wrote:
> Breakpoints.
can be done
>   The ability to monitor registers and change their values
> on the fly.
can be done
>   Single stepping through code.
can be done
>   The ability to alter the
> PC to begin execution of the code at a specific location.
can be done
>   The fact
> that you don't need to use the serial port for it, so you can debug a
> serial application with it (it DOES cost two pins, but those are two
> of the least painful pins to lose, since they have relatively few
> peripherals associated with them).  The ability to do a hardware
> reset.
>  
don't know
> FAR more powerful than serial debugging.  FAR FAR FAR more powerful.
>  
I'm willing to believe you, but I'm not convinced ;-)
Maarten Hofman mentioned stack traces, is that possible ?

Maybe it's the speed, serial debugging can be done at 1.25 MBaud,
is ICD faster ?

Are there any specifications about the ICD and maybe the commands ?

The reason why all these questions ...
... I've the wild intention to create a combination of
- programmer
- uploader for a bootloader (probably Tiny)
- high language debugger (with graph capabilities) + interaction with IDE
- tuning device (e.g. PID tuning)
- rapid prototyping board
Most of the above I've already done, except the combination of it all ;-)

Here is a first attempt of my JAL debugging
 http://oase.uci.kun.nl/~mientki/data_www/pic/jalcc/help/jalcc_icd.html

cheers,
Stef Mientki

2006\05\12@152306 by Herbert Graf

flavicon
face
On Fri, 2006-05-12 at 20:08 +0200, Stef Mientki wrote:
> I'm not familiar with ICD debugging,
> and can't find this information on Microchip's site.
>
> To me the ICD debugging technique looks almost identical to so called
> serial debugging.
> As most of my designs already have a serial RS232 (or USB) connection,
> I think it would be as good as ICD,
> or even better, because you don't spoil any extra pins.

I'm not sure what you mean by "serial debugging", are you using a tool
that accessing something running in the PIC over serial? Or are you just
talking about "printf" type debugging?

> So what's the real advantage of ICD over RS232 ?

Lots, but offhand, to me, these are the biggies:

- single step code, with live updates
- view any FSR or memory location at any time
- breakpoints pretty much anywhere in the code
- when using an HLL all debugging happens at the HLL level, no need to
go down to the assembly listing

You give up some IO yes, but ever since getting the ICD2 I've NEVER gone
back.

TTYL

2006\05\12@152721 by Herbert Graf

flavicon
face
On Fri, 2006-05-12 at 21:13 +0200, Stef Mientki wrote:
> thanks Mike,
>
> but ...
> ... a lot of (may all) things you mentioned, can be done through serial

Can be done yes, but why reinvent the wheel?

Plus, with serial debugging you can't debug when you use that serial
port, a big issue for me since my of my projects have used one.

I'm not saying the ICD is the only way to go, but considering how easy
it is to use, and how integrated it is with MPLAB it's by far the best
solution for me.

TTYL

2006\05\12@152804 by Spehro Pefhany

picon face
At 09:13 PM 5/12/2006 +0200, you wrote:
>thanks Mike,
>
>but ...
>... a lot of (may all) things you mentioned, can be done through serial

Sure, if you allow re-writing of the flash to insert breakpoints (slow),
as opposed to the dedicated hardware breakpoint (fast to change, but
only a single breakpoint) but your monitor program will consume some
program memory. Using ICD will also allow you to debug your serial
handling routines in a realistic situation, which might be a bit
difficult if you're using the port for debugging.

Also the integration with MPLAB allows you to single-step through the
code in the edit window. That's not possible with debugging using a
serial monitor. It *could* be done, just that it hasn't been..

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
.....speffKILLspamspam@spam@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->>Test equipment, parts OLED displys http://search.ebay.com/_W0QQsassZspeff


2006\05\12@152834 by Maarten Hofman

face picon face
>
> > Breakpoints.
> can be done


You mean you can add code to your code that stops the code at that location,
or can I have a live program that was already compiled, possibly someone
else's HEX file, and send a command over the RS-232 or USB port to stop at
memory location 56?

>   The ability to monitor registers and change their values
> > on the fly.
> can be done


Again, by adding code, or can I just send a command over RS-232 to a foreign
HEX file, and retrieve the data I want?

>   Single stepping through code.
> can be done
> >   The ability to alter the
> > PC to begin execution of the code at a specific location.
> can be done


Do I have to recompile my program with code added to the location where I
want to change the PC?

{Quote hidden}

Not sure, but the debugger can always keep track of each time something is
put on the stack and removed from the stack, and create a trace that way. On
the other hand, I'd imagine Microchip's proprietary debug protocol would
allow reading of the stack registers as well.

Maybe it's the speed, serial debugging can be done at 1.25 MBaud,
> is ICD faster ?
>
> Are there any specifications about the ICD and maybe the commands ?


I doubt it, so far I always understood it to be rather proprietary. However,
the system used for it is pretty well known, and you can reuse the code from
Microchip in order to create your own device.

Greetings,
Maarten Hofman.

2006\05\12@153351 by Wouter van Ooijen

face picon face
> [ICD2 debugging]
> FAR more powerful than serial debugging.  FAR FAR FAR more powerful.

In some situation yes, but I have an ICD2 at my desk yet I seldom use
it. I often prefer serial logging, because it does not disturb the
timing of the application much (at least not when you limit your
debugging info). And you can do serial logging with any pin you want, a
software UART is not that difficult.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2006\05\12@155741 by Bob Axtell

face picon face
Stef Mientki wrote:
{Quote hidden}

I am becoming increasingly disappointed at MicroChip's failure to
release the protocol for the ICD2.
There is simply NO excuse for it. The ICD2 is a really disappointing
piece of test equipment, not really
worth $150.

Before ICD2, I debugged very complex code using an RS232 interface to
uPs. I have since developed an
interface using manchester code which is independent of oscillator
speed.  But in any case I was always able
to:

1. See any ram space.
2. Change any register or block of registers..
3. Force execution at a certain place (but afterward, a WDT would force
a timeout reset to correct the stack).

The manchester code means that a single pin (not two pins!) can send
commands and receive data from the
device, albeit slower than the ICD2 (because it is just one pin, thruput
is less than half). It would be nice to
run the manchester interface code through the PGM pin, which is useless
90% of the time anyway. I can fit
the code and bootloader into 256 code words. Remember that the
configuration byte can't be changed in
this way, but I think I CAN squeeze in writes to the EEPROM.

I'd be interested in supporting you in this for the PIC16F87XX,
PIC16F8X, and a few selected PIC18Fxxx. I
can easily handle the bootloaders, and can interface a FT232R for you (a
VERY nice component- NO clocks
needed, and it can supply 6/12/24mhz clock, too) if RS232 is used. It is
not helpful for devices that can't be
programmed thru a bootloader.

--Bob

2006\05\13@103222 by Xiaofan Chen

face picon face
On 5/13/06, Bob Axtell <engineerspamKILLspamcotse.net> wrote:
> I am becoming increasingly disappointed at MicroChip's failure to
> release the protocol for the ICD2.
> There is simply NO excuse for it. The ICD2 is a really disappointing
> piece of test equipment, not really worth $150.
>

I am also a bit disappointed that Microchip is so reluctant to release
the protocol for ICD2 and on-chip debugging info for PIC18/PIC14/dsPICs.

Still I think ICD2 is worth the money since it is still much cheaper than
ICE2000/ICE4000. In fact it is even cheaper than a processor module.
ICE2000/ICE4000 are again worth their money if the project budget
allows to buy them.

Regards,
Xiaofan

2006\05\13@142722 by Gerhard Fiedler

picon face
Wouter van Ooijen wrote:

>> [ICD2 debugging]
>> FAR more powerful than serial debugging.  FAR FAR FAR more powerful.
>
> In some situation yes, but I have an ICD2 at my desk yet I seldom use
> it. I often prefer serial logging, because it does not disturb the
> timing of the application much (at least not when you limit your
> debugging info). And you can do serial logging with any pin you want, a
> software UART is not that difficult.

Exactly my approach, too. I pretty much never have to step through live
code. If there's something that needs stepping through, it's in most cases
a small, limited piece of code and a simulator (or a brain :) is way more
convenient. (The ICD2 steps really slowly.) My other debugging challenges
usually involve the whole application and its realtime behavior together
with the process -- and stepping through any of this wouldn't do me much
good. Neither does the possibility to set any SFRs seem to be very
important to me; the phase to figure out how to configure a new peripheral
seems to be quite short.

For debugging the realtime application behavior, serial logging is a real
godsend; especially if it's already planned into the design. I use debug
macros that either insert print statements that can be controlled by bits
on a file-by-file basis (each file has eight categories of print statements
available) or nothing (for release builds). If during testing I have a
certain "question" for a certain piece of code, I just enable one or more
of these bits. Of course, sometimes I have to add extra print macros for
that (because I didn't anticipate the "question" when writing the code) and
re-program the chip, but then to disable these again is just a matter of
setting the bit to 0 -- no temporary inserting and removing of debug code
necessary. The statements remain available if needed later (or when
re-using that piece of code in a different application).

I do have an ICD2 here, but for these reasons I pretty much exclusively use
it as an ICSP programmer.

BTW, there's nothing that says that you can't do a half-duplex serial
connection through one pin. What one usually sends back to the processor in
such a scenario are simple, slow commands with a few characters (for
example to set or clear such a print control bit).

Gerhard

2006\05\13@153305 by Vasile Surducan

face picon face
On 5/12/06, Spehro Pefhany <.....speffKILLspamspam.....interlog.com> wrote:
> At 09:13 PM 5/12/2006 +0200, you wrote:
> >thanks Mike,
> >
> >but ...
> >... a lot of (may all) things you mentioned, can be done through serial
>
> Sure, if you allow re-writing of the flash to insert breakpoints (slow),
> as opposed to the dedicated hardware breakpoint (fast to change, but
> only a single breakpoint) but your monitor program will consume some
> program memory. Using ICD will also allow you to debug your serial
> handling routines in a realistic situation, which might be a bit
> difficult if you're using the port for debugging.
>
> Also the integration with MPLAB

And what if you need debugging without using MPLAB ?
I think Stef is not debugging assembler code but jal code. Inserting a
breakpoint
into the assembler file created by compiler is not as usefull as
understanding where should be the breakpoint into the high level
source. That's why the need for a debugging tool incompatible with
MPLAB.

Vasile


allows you to single-step through the
{Quote hidden}

> -

2006\05\14@044822 by Stef Mientki

flavicon
face
thank you all for your comments,
I think I've the picture complete now,
and as I intend to only use HLL (indeed Vasile) it has no use whatsoever.

(and for the other thread, as I was developing a universal pic programmer,
as a module on the Rapid Prototyping Board, (developing = 5 resistors, 4
capacitors + 1 FET ;-),
and I was considering if it should have an extra RJ11 connector for ICD)

What still amazes me is,
why does Microchip tries to keep the details of ICD so secret ?

cheers,
Stef Mientki

Vasile Surducan wrote:
{Quote hidden}

>> --

2006\05\14@111444 by Herbert Graf
flavicon
face
On Sun, 2006-05-14 at 10:48 +0200, Stef Mientki wrote:
> thank you all for your comments,
> I think I've the picture complete now,
> and as I intend to only use HLL (indeed Vasile) it has no use whatsoever.

For MPLAB supported HLLs the ICD2 is great.

> What still amazes me is,
> why does Microchip tries to keep the details of ICD so secret ?

Considering how "open" MCHIP is with alot of their tech, my only guess
is it's their legal eagles telling them they can't release the details.
It's possible there's certain tech involved in the ICD2 connection that
restricts them from making the info public, I'm not sure. That's my only
guess.

TTYL

More... (looser matching)
- Last day of these posts
- In 2006 , 2007 only
- Today
- New search...