Searching \ for '[PIC] ICD2 debugging without MPLAB and even withou' 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: 'ICD2 debugging without MPLAB and even withou'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] ICD2 debugging without MPLAB and even withou'
2006\01\02@212515 by Chen Xiao Fan

face
flavicon
face

I just received January 2006 news letter from Hi-Tech.
It seems that they are doing quite well in adding support
for Mac OS X and adding Eclipse based Hi-Tide IDE.
Still ICD2 support is the major issue that prevents
customers to use alternative OS like Linux/OS X/Solaris.
Therefore they are working on adding ICD2 support
(should include both programming and debugging)
beyond MPLAB and even beyond the Windows OS limitation.

Of course there is a price to pay. HiTech PICC is not
that cheap so it is not really meant for hobbyists.
It is still good that HiTech is taking care of the
niche market for alternative OS (I guess not many
companies are using non-Windows OS for PIC
development).

There are some open source projects which are aiming
to bring ICD2 programming function to Linux. But I
guess it is difficult to add debugging function without
access to Microchip debugging protocol.

>From one of Olin's previous post it seems to me that
Olin is also working on a possible USB based ICD2
replacement and he has access to Microchip ICD2
protocol under NDA. His post is attached below.
I think that will be a nice product.

Regards,
Xiaofan


On 12/18/05, Olin Lathrop <spam_OUTolin_piclistTakeThisOuTspamembedinc.com> wrote:

> But I'm experimenting with that concept now anyway.  I'll get the first
> boards back next week and am working on the BOM and ordering parts for the
> first 3 prototypes right now.  This programmer (tentatively called the
> EasyUSB) will have full variable Vpp and Vdd plus decent PGC and PGD drive
> that can be shorted to ground or Vdd indefinitely without damage.  It will
> be completely powered from the USB, although I'm adding pads for external 5V
> and serial connection which will be useful at least for debugging.  It
> should be easy to get the serial working first, then dig into the USB part
> on both the PIC and the host.  That may take a few months.
...
> I'm also making the hardware capable of being a debugger.  Unfortunately
> that's the easy part.  Making it work in MPLAB as a debugger won't be
> trivial, and I'm not sure I'll do it.  For now I'm just making sure the
> hardware and firmware are capable and allow dealing with the host side MPLAB
> issues later.  If this ever gets done, it should be a very nice alternative
> to the ICD2 for probably around 1/4 to 1/3 the cost.
>


2006\01\03@074845 by olin piclist

face picon face
Chen Xiao Fan wrote:
> From one of Olin's previous post it seems to me that
> Olin is also working on a possible USB based ICD2
> replacement and he has access to Microchip ICD2
> protocol under NDA.

I'm working on a USB based programmer, but am also making sure it is capable
of being a debugger.  The major distinguishing features of this programmer
will be:

* Fairly low impedence (270 ohm) drive on PGC and PGD to be more tolerant of
various target circuits.

* Variable Vdd, so can do verifications at the Vdd limits of the device.

* Variable Vpp ON voltage to support newer chips that have a maximum Vpp
spec below the old standard of 13V.

* All lines can go to high impedence to allow most target circuits to run
normally with the programmer still connected.

* Analog readback of Vdd and Vpp to verify the desired levels are reached
and for user feedback.

* Readback of PGC also to support operation as debugger.

* Can test for target driving PGD to aid in automatic detection of target
PIC type without causing permanent state changes.

* PGC and PGD can be shorted to any voltage from ground to Vdd indefinitely
without harm to the programmer.

* Connects to host via USB.

* Completely powered from the USB.

* Can provide significant target power while only powered from the USB.  The
details are still undetermined, but I think the spec will be at least 100mA
over the 0-6V Vdd range.

* Can be powered from the USB but communicate via serial to the host.  A TTL
to RS-232 serial adapter and cable will be needed for this.

* Can be separately powered with about 3-6V DC and communicate over serial
to host (TTL - RS-232 adapter needed).


The interface spec and host software will be open.  The same protocol will
be used as other Embed Inc programmers and the same host software will be
able to drive any such programmer.  The firmware may be made available to
select parties to be decided on a case by case basis.

I just got the first prototype board a few days ago.  So far things are
looking good.  The power supplies and PGC/PGD drives are all working
properly, the 18F2550 is running fine, and serial communication is working.
I'm about half way thru adapting the ProProg firmware to the new hardware.
I plan on bringing it up as a serial programmer first, then implementing USB
support on a stable base.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\01\03@080018 by Michael Rigby-Jones

picon face


>-----Original Message-----
>From: .....piclist-bouncesKILLspamspam@spam@mit.edu [piclist-bouncesspamKILLspammit.edu]
>Sent: 03 January 2006 12:51
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC] ICD2 debugging without MPLAB and even
>without Windows
>
>
>Chen Xiao Fan wrote:
>> From one of Olin's previous post it seems to me that
>> Olin is also working on a possible USB based ICD2
>> replacement and he has access to Microchip ICD2
>> protocol under NDA.
>
>I'm working on a USB based programmer, but am also making sure
>it is capable of being a debugger.


Olin,

Will this be designed to be used in conjuction with MPLAB (as a debugger) or are you developing your own debugger software (which would be I lot of work I would think?).

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2006\01\03@085737 by olin piclist

face picon face
Michael Rigby-Jones wrote:
> Will this be designed to be used in conjuction with MPLAB (as a
> debugger) or are you developing your own debugger software (which would
> be I lot of work I would think?).

For now I'm just making sure the capability is there and brought to a
procedural interface on the host.  The only real difference between a
programmer and debugger is that a debugger must be able to let the target
drive PGC and then read back the result.

If I do anything with the debugger feature, it will most likely be creating
and interface between MPLAB and my existing procedural programmer interface.
Unfortunately the MPLAB interface is rather complicated.  It's not just
implementing at few calls in a DLL someplace.  We'll see.  First I've got to
get it working as a USB programmer.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\01\03@104654 by Jesse Lackey

flavicon
face
This sounds great.  This sounds like what ICD2 should have been all
along!  Here are my unsolicited additional feature requests... :)

Works with hubs!  (powered hubs).  The ICD2 is totally erratic.

Target powering at 3.3V instead of 5V (actually a settable voltage from
2 or so to 5 would be super).

Some means of knowing when target is drawing more current than can be
supplied by the programmer.

A way of sending serial to a hyperterminal-type display via the
programmer.  I always have some way to do debugging/status printf() from
PIC to PC; and I have to connect a TTL->RS232 converter for this.  Would
be just dandy to be able to do this via USB with the programmer, as an
additional signal on the programming cable.  (This could be significant
effort and hassle, I know...)

Able to withstand a short of Vdd/Vpp to ground, if possible.  This
allows the programmer to be used with completely untested boards,
instead of having to use a current-limit supply for first power-up.

> The interface spec and host software will be open.
Yay!  Calling all linux and Mac people...

Sounds great!
J




Olin Lathrop wrote:
{Quote hidden}

2006\01\03@113746 by Gerhard Fiedler

picon face
Jesse Lackey wrote:

> Works with hubs!  (powered hubs).  The ICD2 is totally erratic.

Mine works fine. PC -> hub -> 4 m cable -> ICD2. I use it mostly in
programmer mode, though.

> Some means of knowing when target is drawing more current than can be
> supplied by the programmer.

Especially because you might not know how much current is available to the
programmer through USB.

Gerhard

2006\01\03@114024 by olin piclist

face picon face
Jesse Lackey wrote:
> Works with hubs!  (powered hubs).  The ICD2 is totally erratic.

I don't see how it couldn't as long as the hub adheres to the USB spec.  It
probably won't work with unpowered hubs because it will probably ask for the
maximum power and refuse to go if it can't get it.

> Target powering at 3.3V instead of 5V (actually a settable voltage from
> 2 or so to 5 would be super).

It has variable Vdd from 0 to 6 volts.

> Some means of knowing when target is drawing more current than can be
> supplied by the programmer.

No problem.  First you'll see it, then you'll hear it, then you'll smell it.

Seriously though, there is no facility to measure target power draw.  The
programmer will definitely protect itself from damage if Vdd and Vpp are
shorted to ground, but I'm not sure yet whether it will otherwise continue
to operate correctly.  I'm not sure yet how much power supply can handle.
There may be a tradeoff between that, the ability to accomodate a wide input
voltage range, response time, and efficiency.

> A way of sending serial to a hyperterminal-type display via the
> programmer.

Very unlikely.  If I implement debugging at all, it will be to fit into the
MPLAB framework.  I don't believe that has any such capability, and I don't
see how you would want to control that anyway.

> I always have some way to do debugging/status printf() from
> PIC to PC; and I have to connect a TTL->RS232 converter for this.

Hmm.  I sell TTL to RS-232 converters, so I'm no seeing how this is a bad
thing ;-)

> Would
> be just dandy to be able to do this via USB with the programmer, as an
> additional signal on the programming cable.  (This could be significant
> effort and hassle, I know...)

There is definitely not room for an additional signal.  I could possibly
provide access to the serial port from the USB, but I still don't see how
you expect the host interface for that to work.  Adding commands for that to
the protocol is relatively easy, but then what?

> Able to withstand a short of Vdd/Vpp to ground, if possible.  This
> allows the programmer to be used with completely untested boards,
> instead of having to use a current-limit supply for first power-up.

It will definitely tollerate such short without damage, not sure about
continuing with proper operation though.

>> The interface spec and host software will be open.
> Yay!  Calling all linux and Mac people...

The interface spec and host software for the existing programmers are
already available at http://www.embedinc.com/picprg/sw.htm.  These will be
enhanced to support the new features of this programmer, but will otherwise
be basically the same.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\01\03@161103 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

>> Would be just dandy to be able to do this via USB with the programmer,
>> as an additional signal on the programming cable.  (This could be
>> significant effort and hassle, I know...)
>
> There is definitely not room for an additional signal.  I could possibly
> provide access to the serial port from the USB, but I still don't see
> how you expect the host interface for that to work.  Adding commands for
> that to the protocol is relatively easy, but then what?

I think the idea is that while the programmer is not programming, these two
lines can work as async or sync serial rx/tx. The DUT needs to have the
appropriate firmware to send/receive data according to the defined format,
the programmer has something similar, and transfers this data through the
USB. The USB driver on the PC could (to make it comfortable) provide a
serial port that sees only this traffic.

Gerhard

2006\01\03@162455 by olin piclist

face picon face
Gerhard Fiedler wrote:
> I think the idea is that while the programmer is not programming,
> these two lines can work as async or sync serial rx/tx. The DUT needs
> to have the appropriate firmware to send/receive data according to
> the defined format, the programmer has something similar, and
> transfers this data through the USB. The USB driver on the PC could
> (to make it comfortable) provide a serial port that sees only this
> traffic.

I suppose that could be done, but it would be a lot of work just to avoid a
wire and an adapter to a real serial port.  If the communication was always
one way, like from the target to the programmer, it would definitely be
easier.  In any case writing a full compliant serial port driver is also a
chunk of work.  It would be a lot easier to provide a call in the programmer
library that can receive the debug byte stream from the target.

There is nothing stopping anyone from implementing this now if they really
want to.  The EasyProg firmware, protocol, and host source code are all
available at http://www.embedinc.com/picprg/sw.htm.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\01\05@041830 by Chen Xiao Fan

face
flavicon
face

> -----Original Message-----
> From: .....piclist-bouncesKILLspamspam.....mit.edu
> [EraseMEpiclist-bouncesspam_OUTspamTakeThisOuTmit.edu] On Behalf
> Of Olin Lathrop
> Sent: Wednesday, January 04, 2006 12:41 AM
>
>> Some means of knowing when target is drawing more current
>> than can be supplied by the programmer.
>
> Seriously though, there is no facility to measure target
> power draw.
>
>> Able to withstand a short of Vdd/Vpp to ground, if possible.  This
>> allows the programmer to be used with completely untested boards,
>> instead of having to use a current-limit supply for first power-up.
>
> It will definitely tolerate such short without damage, not sure about
> continuing with proper operation though.

Maybe it is easier to put a fuse there. How will you implement
short circuit protection? It will most likely make the
circuits more complex.

Another problem is over-voltage protection of PGC/PGD.
This may be a secondary consideration but ESD can kill the
programmer. Maybe a 6V2 zener is good to have on PGC/PGD.

>>> The interface spec and host software will be open.
>> Yay!  Calling all linux and Mac people...
>
> The interface spec and host software for the existing programmers are
> already available at http://www.embedinc.com/picprg/sw.htm.  
> These will be enhanced to support the new features of this programmer,
> but will otherwise be basically the same.
>
Not so sure why there have not been any alternative host programs
for Easyprog. Maybe there are already too many PIC programmers
in the market. There are Xwisp2 for Wisp628, pk2/pyk for PICkit 2
and many others for simple programmers under Linux and possibly
Mac OS X and even FreeBSD and OS/2. Maybe they are already good
enough. On top of these, there are cheap ICD2 clones and PS+ clones.

But the ICD2 debugging ability will definitely be a big plus
if it is implemented. However I guess then Olin may not
be able to open the host software due to the NDA...

Regards,
Xiaofan


2006\01\05@082412 by olin piclist

face picon face
Chen Xiao Fan wrote:
> Maybe it is easier to put a fuse there. How will you implement
> short circuit protection? It will most likely make the
> circuits more complex.

I don't like fuses because they take a lot of board space and are a hassle
to deal with.  I have designed the circuit so that the current the circuit
can deliver is inherently limited, and made sure the circuit can take the
worst case dissipation caused by a short.  Something will get warm, but it
will all be within spec.

> Another problem is over-voltage protection of PGC/PGD.
> This may be a secondary consideration but ESD can kill the
> programmer. Maybe a 6V2 zener is good to have on PGC/PGD.

Yes, there are an infinite number of things one can do to decrease the
chance of damage, but they cost an infinite amount too.  No matter what I
do, there will be some type of abuse that can cause permanent damage.  Would
you rather have a $50 thing that can handle 99% of abuse, or a $100 thing
that can handle 99.9% of abuse?

> But the ICD2 debugging ability will definitely be a big plus
> if it is implemented. However I guess then Olin may not
> be able to open the host software due to the NDA...

I can't release the interface spec to MPLAB, which might cover my code that
acts as the glue between MPLAB and my programmer software.  However the
PICPRG library and programmer communications protocol are my own and
Microchip has nothing to say about who I release it to.  If I do create an
MPLAB interface it will be a glue layer above the PICPRG library.  I don't
see why anyone would want to mess with this layer anyway since it would
already do the only one thing it could do.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\01\05@102858 by Howard Winter

face
flavicon
picon face
Olin,

On Thu, 5 Jan 2006 08:25:26 -0500, Olin Lathrop wrote:

>...
> If I do create an
> MPLAB interface it will be a glue layer above the PICPRG library.  I don't
> see why anyone would want to mess with this layer anyway since it would
> already do the only one thing it could do.

If you are doing an ICD2 replacement, will it be able to handle the special headers that Microchip make, that
are used for debugging chips that don't allow it when they're "naked", such as the 16F688 (part number for the
header for this is AC162056)?  

For those who don't know, these adaptor/headers are a small board fitted with a special version of the PIC, in
this case called 16F688-ICD, which has more pins than usual to add the debug functionality, and the whole
thing plugs into the target board where the PIC will go.  It has an RJ12 socket to connect to an ICD2, hence
my question above.

Cheers,


Howard Winter
St.Albans, England


2006\01\05@111751 by olin piclist

face picon face
Howard Winter wrote:
> If you are doing an ICD2 replacement, will it be able to handle the
> special headers that Microchip make, that are used for debugging chips
> that don't allow it when they're "naked", such as the 16F688 (part
> number for the header for this is AC162056)?
>
> For those who don't know, these adaptor/headers are a small board
> fitted with a special version of the PIC, in this case called
> 16F688-ICD, which has more pins than usual to add the debug
> functionality, and the whole thing plugs into the target board where
> the PIC will go.  It has an RJ12 socket to connect to an ICD2, hence my
> question above.

First I want to point out I'm doing a USB programmer.  Because it's only a
little more trouble, I'm also making the hardware capable of being a
debugger.  It's a LOT more trouble to interface it with MPLAB, so I'm not
promising that will ever happen.

I am not that familiar with the debug versions of these small PICs.
However, if they connect to the normal RJ-12 on the ICD2, then I expect that
it could work.  The software support is the big question.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2006\01\05@121754 by Howard Winter

face
flavicon
picon face
Olin,

On Thu, 5 Jan 2006 11:19:10 -0500, Olin Lathrop wrote:

>...
> First I want to point out I'm doing a USB programmer.  Because it's only a
> little more trouble, I'm also making the hardware capable of being a
> debugger.  It's a LOT more trouble to interface it with MPLAB, so I'm not
> promising that will ever happen.
>
> I am not that familiar with the debug versions of these small PICs.
> However, if they connect to the normal RJ-12 on the ICD2, then I expect that
> it could work.  The software support is the big question.

OK, understood!

Cheers,


Howard Winter
St.Albans, England


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