Post by thread:[PIC] ICD2 debugging without MPLAB and even withou

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

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

>-----Original Message----- >From: .....piclist-bouncesKILLspam@spam@mit.edu [piclist-bouncesKILLspammit.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. =======================================================================

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

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}> 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

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

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

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

> -----Original Message----- > From: .....piclist-bouncesKILLspam.....mit.edu > [EraseMEpiclist-bouncesspam_OUTTakeThisOuTmit.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

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

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

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