Post by thread:[PIC] DsPIC programmer

Bob Axtell wrote: > DIY electronics plans to have its K128 Programmer doing DsPICs within a > month. I plan to have it within a week > Lord what a programming algorithm... Argh. Don't get me started. All the ambiguities and some errors in the programming spec don't help either. It took trial and error to get most things working. The spec can only be considered a hint. At this point I've got all reading and writing of program and data memory working, and have only a few additions to the high level host code left to do. This has taken waaaaay longer than I expected based on experience with other PICs. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

Its keeping me off the streets and out of poolhalls. --Bob Olin Lathrop wrote: {Quote hidden}> Bob Axtell wrote: > >> DIY electronics plans to have its K128 Programmer doing DsPICs within a >> month. > > > I plan to have it within a week > >> Lord what a programming algorithm... > > > Argh. Don't get me started. All the ambiguities and some errors in the > programming spec don't help either. It took trial and error to get most > things working. The spec can only be considered a hint. > > At this point I've got all reading and writing of program and data memory > working, and have only a few additions to the high level host code > left to > do. This has taken waaaaay longer than I expected based on experience > with > other PICs. > > > ***************************************************************** > Embed Inc, embedded system specialists in Littleton Massachusetts > (978) 742-9014, http://www.embedinc.com -- Note: To protect our network, attachments must be sent to .....attachKILLspam@spam@engineer.cotse.net . 1-866-263-5745 USA/Canada http://beam.to/azengineer

>Bob Axtell wrote: > > DIY electronics plans to have its K128 Programmer doing DsPICs within a > > month. > >I plan to have it within a week > > > Lord what a programming algorithm... Olin replied. >Argh. Don't get me started. All the ambiguities and some errors in the >programming spec don't help either. It took trial and error to get most >things working. The spec can only be considered a hint. > >At this point I've got all reading and writing of program and data memory >working, and have only a few additions to the high level host code left to >do. This has taken waaaaay longer than I expected based on experience with >other PICs. At least you have the "d" revision to work with. When I added dsPIC support I had to hand check every opcode in the STDP algorithm. There seemed to be an op-code error on every page (or is that still the case...) I cannot believe it took microchip four goes to even get the config bit map correct! Anyway, I don't know if anyone is even using the WARP-13 for dsPIC support. I only ever heard from one person who was having problems and I never got an update from him when I enquired for more info. I know that it worked as far as getting the executive programmed and running correctly and it cross check ok when I tested with a ICD2 . That is a far as I played with it. Personally, I think it is all a bit dubious anyway as anyone who is serious about developing with the dsPIC really is going to need a ICD. Offering someone a programmer so they don't get an ICD would be a bit of a disservice in many cases. Of course if the programmer offers some substantial other benefit then having both would be a good idea. Regards, Jim subject=Re:[PIC:] DsPIC programmer source= http://www.piclist.com/piclist/2005/02/16/140626a.txt

Jim Robertson wrote: {Quote hidden}>> Bob Axtell wrote: >> > DIY electronics plans to have its K128 Programmer doing DsPICs >> within a >> > month. >> >> I plan to have it within a week >> >> > Lord what a programming algorithm... > > > Olin replied. > >> Argh. Don't get me started. All the ambiguities and some errors in the >> programming spec don't help either. It took trial and error to get most >> things working. The spec can only be considered a hint. >> >> At this point I've got all reading and writing of program and data >> memory >> working, and have only a few additions to the high level host code >> left to >> do. This has taken waaaaay longer than I expected based on >> experience with >> other PICs. > > > At least you have the "d" revision to work with. > > When I added dsPIC support I had to hand check every opcode in the > STDP algorithm. There seemed to be an > op-code error on every page (or is that still the case...) > > I cannot believe it took microchip four goes to even get the config > bit map correct! > > Anyway, I don't know if anyone is even using the WARP-13 for dsPIC > support. I only ever heard from one > person who was having problems and I never got an update from him when > I enquired for more info. > > I know that it worked as far as getting the executive programmed and > running correctly and it cross check ok > when I tested with a ICD2 . That is a far as I played with it. > > Personally, I think it is all a bit dubious anyway as anyone who is > serious about developing with the dsPIC really is > going to need a ICD. Offering someone a programmer so they don't get > an ICD would be a bit of a disservice > in many cases. > > Of course if the programmer offers some substantial other benefit > then having both would be a good idea. > I'm designing a production programmer for DIY (Peter Crowcroft) so it has an application past development-only applications. Just looking at it objectively, it seems they left programming out until the last minute (celebration had started early), then fumbled around trying to squeeze a bit in here and there. --Bob {Quote hidden}> Regards, > > Jim > > > > > > > > > > subject=Re:[PIC:] DsPIC programmer > source= http://www.piclist.com/piclist/2005/02/16/140626a.txt > -- Note: To protect our network, attachments must be sent to attachKILLspamengineer.cotse.net . 1-866-263-5745 USA/Canada http://beam.to/azengineer

Howard Winter wrote: > Oops - whatever happened to "When all else fails, read the > instructions" (or the spec)? I did, carefully, many times, with notes all over now about how things really work. > I take it you're doing this for the ProProg? It hardly matters to me > as I may never get round to using dsPICs, but will the EasyProg be > capable too? Yes, I'm doing this for the ProProg now. Once that's done, I haven't decided yet whether to add dsPIC capability to the EasyProg firmware or postpone that a bit in favor of adding some of the new 16F "A" parts like the 16F877A to both programmers. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

Olin, On Wed, 16 Feb 2005 16:53:03 -0500, Olin Lathrop wrote: > Howard Winter wrote: > > Oops - whatever happened to "When all else fails, read the > > instructions" (or the spec)? > > I did, carefully, many times, with notes all over now about how things > really work. Right - I wasn't criticising, just bemoaning the fact that the "when all else fails" option is no longer enough! > > I take it you're doing this for the ProProg? It hardly matters to me > > as I may never get round to using dsPICs, but will the EasyProg be > > capable too? > > Yes, I'm doing this for the ProProg now. Once that's done, I haven't > decided yet whether to add dsPIC capability to the EasyProg firmware or > postpone that a bit in favor of adding some of the new 16F "A" parts like > the 16F877A to both programmers. OK, for what it's worth my vote goes for the latter. Keep up the good work, and thanks! Cheers, Howard Winter St.Albans, England

Jim Robertson wrote: > Personally, I think it is all a bit dubious anyway as anyone who is > serious about developing with the dsPIC really is > going to need a ICD. I agree, which is why I don't see dsPIC support for the EasyProg as a big deal. However, it does make sense for the ProProg. The ICD2 and MPLAB is really for developers, but there are other occasions where PICs need to be programmed by people that don't know anything about the code itself and that you really don't want running a debugger. The primary case is in a production fixture, but there are also the occasional field upgrades and the like. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

On Thu, 2005-02-17 at 18:14 +1100, Jim Robertson wrote: > Anyway, I don't know if anyone is even using the WARP-13 for dsPIC support. > I only ever heard from one > person who was having problems and I never got an update from him when I > enquired for more info. Just to pipe up, I don't know if I was the one you were talking to (I did email you a couple things), but I did get my Warp13 working with the 2011. Worked quite well too, once I added the Olin "cap and resistor" thing. Of course, shortly after I got it working I received an ICD2 (which also required the "cap and resistor" thing). I'm not sure I'd consider having an ICD a REQUIREMENT of using the dsPIC, but it sure does make life easier. TTYL ----------------------------- Herbert's PIC Stuff: http://repatch.dyndns.org:8383/pic_stuff/

Stephen D. Barnes wrote: >> Just to pipe up, I don't know if I was the one you were talking to (I >> did email you a couple things), but I did get my Warp13 working with >> the 2011. Worked quite well too, once I added the Olin "cap and >> resistor" thing. >> >> Of course, shortly after I got it working I received an ICD2 (which >> also required the "cap and resistor" thing). I'm not sure I'd >> consider having an ICD a REQUIREMENT of using the dsPIC, but it sure >> does make life easier. > > I have done some searching and cannot find out what this "cap and > resistor" thing is. > anyone care to elaborate or post a link? Programming is done with two digital lines called PGC (clock) and PGD (data). These lines are right next to each other in the standard Microchip programming cable with RJ-12 plugs on each end. The problem comes from edges on one of these lines coupling onto the other. Since the programmer always drives the PGC line, this can be handled in the programmer by a little filtering. However, during readback the target chip drives the PGD line. Sharp eges on that can and do couple onto the PGC line, especially when a dsPIC is driving the line, probably because these have faster output drivers. The noise coupled from PGD to PGC looks like extra clocks at the target chip, which cause the programmer and target to get out of sync and communication to break down. Unfortunately, the whole effect can happen within the propagation time from the target chip to the programmer and back (I estimate about 7nS), so there is absolutely nothing that can be done at the programmer end to fix this. My solution is to add a 22pF cap to ground on each of the PGC and PGD lines on the target board. I also add a 100ohm resistor in the PGD line between the target chip and the cap. The resistor and cap on the PGD line form a low pass filter that removes attenuates high frequencies (from the sudden edges) going onto the PGD line when driven by the target. The cap on the PGC line makes it less susceptible to coupled noise. In practise, just a 22pF cap on PGD right at the target PIC fixes the problem most of the time. I've never seen it fail with a 22pF cap on both lines, but I add the resistor to target boards just to make sure. I've been doing this for over a year now, and all such target boards can be reliably programmed and debugged using the ICSP interface. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

This might be a dumb question, Olin. Why not just make up your own cable between the programmer and the target board using a flat cable (i.e. ribbon cable) and separate the PGD and PGC lines by putting the VDD, MCLR, and VSS lines between them (with MCLR in the center)?? Don't change the order of signals on the connectors, just in the cable. This, of course, assumes that the loading on VDD and VSS is heavy enough that the extra "noise" induced on those lines by PGD and PGC won't be noticed. Wouldn't that eliminate the need for the R-C networks on the target circuit? I've not played with your circuit, so I'm speaking from a point of ignorance here. I've done exactly what I'm suggesting on my cable from an ICD2 to my targets and am not having any troubles. Maybe I'm extremely lucky!!! I'd like your input. Dennis Olin Lathrop wrote: {Quote hidden}>Stephen D. Barnes wrote: > > >>>Just to pipe up, I don't know if I was the one you were talking to (I >>>did email you a couple things), but I did get my Warp13 working with >>>the 2011. Worked quite well too, once I added the Olin "cap and >>>resistor" thing. >>> >>>Of course, shortly after I got it working I received an ICD2 (which >>>also required the "cap and resistor" thing). I'm not sure I'd >>>consider having an ICD a REQUIREMENT of using the dsPIC, but it sure >>>does make life easier. >>> >>> >>I have done some searching and cannot find out what this "cap and >>resistor" thing is. >>anyone care to elaborate or post a link? >> >> > >Programming is done with two digital lines called PGC (clock) and PGD >(data). These lines are right next to each other in the standard Microchip >programming cable with RJ-12 plugs on each end. > >The problem comes from edges on one of these lines coupling onto the other. >Since the programmer always drives the PGC line, this can be handled in the >programmer by a little filtering. However, during readback the target chip >drives the PGD line. Sharp eges on that can and do couple onto the PGC >line, especially when a dsPIC is driving the line, probably because these >have faster output drivers. The noise coupled from PGD to PGC looks like >extra clocks at the target chip, which cause the programmer and target to >get out of sync and communication to break down. Unfortunately, the whole >effect can happen within the propagation time from the target chip to the >programmer and back (I estimate about 7nS), so there is absolutely nothing >that can be done at the programmer end to fix this. > >My solution is to add a 22pF cap to ground on each of the PGC and PGD lines >on the target board. I also add a 100ohm resistor in the PGD line between >the target chip and the cap. The resistor and cap on the PGD line form a >low pass filter that removes attenuates high frequencies (from the sudden >edges) going onto the PGD line when driven by the target. The cap on the >PGC line makes it less susceptible to coupled noise. > >In practise, just a 22pF cap on PGD right at the target PIC fixes the >problem most of the time. I've never seen it fail with a 22pF cap on both >lines, but I add the resistor to target boards just to make sure. I've been >doing this for over a year now, and all such target boards can be reliably >programmed and debugged using the ICSP interface. > > >***************************************************************** >Embed Inc, embedded system specialists in Littleton Massachusetts >(978) 742-9014, http://www.embedinc.com > >

On Sun, 2005-02-20 at 12:55 -0500, Olin Lathrop wrote: > My solution is to add a 22pF cap to ground on each of the PGC and PGD lines > on the target board. I also add a 100ohm resistor in the PGD line between > the target chip and the cap. The resistor and cap on the PGD line form a > low pass filter that removes attenuates high frequencies (from the sudden > edges) going onto the PGD line when driven by the target. The cap on the > PGC line makes it less susceptible to coupled noise. > > In practise, just a 22pF cap on PGD right at the target PIC fixes the > problem most of the time. I've never seen it fail with a 22pF cap on both > lines, but I add the resistor to target boards just to make sure. I've been > doing this for over a year now, and all such target boards can be reliably > programmed and debugged using the ICSP interface. As a small note it seems the later run dsPICs don't seem to need this fix anymore. I've gone through a few 3013s and 4011s that didn't need it. Some later 2011 still give me the problem though. TTYL ----------------------------- Herbert's PIC Stuff: http://repatch.dyndns.org:8383/pic_stuff/

> Why not just make up your own cable between the programmer and the > target board using a flat cable (i.e. ribbon cable) and separate the PGD > and PGC lines by putting the VDD, MCLR, and VSS lines between them (with > MCLR in the center)?? It adds a lot more complexity and potential error when others have to do this. Also the RJ-12 connectors crimp onto a predetermined cable that has no provisions for extra conductors. With a lot of kludging, you could make up something like that, but then everyone who uses it would have to also. You can't just tell someone to go use and ICD2. In most cases two caps and a resistor add a lot less cost to a board than whatever connector you are using for the programming interface. In cases of high volume extremely cost and space sensitive products, there will usually be pogo pins connecting to blank pads on the bottom of the board from a custom prodution fixture. In those case it is only a tiny extra burden to add two caps and a resistor to the fixture as close to the pogo pins as possible. > Don't change the order of signals on the > connectors, just in the cable. That is not easy to do with RJ type connectors, which is what you get from the ICD2 and some programmers. On both the EasyProg and ProProg I provided the standard ICD2 connector for compatibility, but also 6 pin connectors for custom cables that have an extra ground line between PGC and PGD. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

On Sun, 2005-02-20 at 18:48 -0500, Olin Lathrop wrote: > > As a small note it seems the later run dsPICs don't seem to need this > > fix anymore. I've gone through a few 3013s and 4011s that didn't need > > it. Some later 2011 still give me the problem though. > > I wouldn't know, I just add the fix all the time. This may have something > to do with process variability, and there is no guarantee that the problem > might not reappear after some future process change or die shrink. True, but since MChip doesn't suggest this fix anywhere (that I've seen) I have a feeling it was something they became aware of in the 2011 and fixed in all other parts. I've only seen the problem with the 2011. Just mentioning an observation, not suggesting any course of action. ----------------------------- Herbert's PIC Stuff: http://repatch.dyndns.org:8383/pic_stuff/

> True, but since MChip doesn't suggest this fix anywhere (that I've seen) I reported this to them well over a year ago, but they seem reluctant to clarify the situation. One of the people I talked to wanted to know if there was a "simple" fix. I think they are worried that they look a little foolish when their ICD2 and their chips and their cable don't work together. They did come out with an ICD2 change that addresses some of the problems some of the time. That seems to be the part line, and it seems they won't admit any problem past that. > I have a feeling it was something they became aware of in the 2011 and > fixed in all other parts. I first discovered diagnosed the problem on a 30F2010. I after applying the fix other places I found that some flaky debugging operation with an ICD2 and a 30F6010 went away. Things seem to be right on the edge. That means some people will see the problem, others will not. There was an earlier post on this thread where someone said this fix made a definite difference for them. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com

> > Anyway, I don't know if anyone is even using the WARP-13 for dsPIC > support. > > I only ever heard from one > > person who was having problems and I never got an update from him when I > > enquired for more info. Herbert Graf wrote {Quote hidden}>Just to pipe up, I don't know if I was the one you were talking to (I >did email you a couple things), but I did get my Warp13 working with the >2011. Worked quite well too, once I added the Olin "cap and resistor" >thing. > >Of course, shortly after I got it working I received an ICD2 (which also >required the "cap and resistor" thing). I'm not sure I'd consider having >an ICD a REQUIREMENT of using the dsPIC, but it sure does make life >easier. > >TTYL Yes, it was you I had in mind. Glad to hear that you got it working. Thanks for your comments, they are important as I need to be confident with what I am offering. BTW. FWIW I have just updated the WARP-13 dsPIC support to the latest specification and re-enabled it. New driver out shortly. There is a beta hidden on the web somewhere. People are welcome to test it. Lots of new 18Fxxxx parts added and a few new dsPICs as well. email .....jimplKILLspam.....newfoundelectronics.com for details. Regards, Jim (ex?) NEWFOUND ELECTRONICS subject=Re:[PIC:] DsPIC programmer source= http://www.piclist.com/piclist/2005/02/17/084615a.txt