Post by thread:[pic:] Wisp628 and 12F5xx PICs.

Hi. It says in the Readme file in the XWisp2 distribution that the 12-bit PICs (such as 12F508/509) are not "supported by Wisp628"... Not much to do about that, I guess, but is there a simple way to describe what's special with these compared to, let's say, the 12F629/675 ? Best Regards, Jan-Erik.

Jan-Erik Soderholm wrote: > Hi. > It says in the Readme file in the XWisp2 distribution > that the 12-bit PICs (such as 12F508/509) are not > "supported by Wisp628"... > > Not much to do about that, I guess, but is there > a simple way to describe what's special with > these compared to, let's say, the 12F629/675 ? > If I read the programming specs of the 12F675, (which by coincidence I'm doing right now ;-) and see the schematic of the wisp628, I don't understand how the wisp628 is able to program a 12F675 .... ... the 12F675 programming specs state ... ... to enter programming mode hold data+clock low, no Vdd, ... rise Vpp, ... wait >5usec ... rise Vdd ... wait >5usec I don't see a switch in the Vdd line ??? cheers, Stef

On 5/23/06, Jan-Erik Soderholm <spam_OUTjan-erik.soderholmTakeThisOuTtelia.com> wrote: > Hi. > It says in the Readme file in the XWisp2 distribution > that the 12-bit PICs (such as 12F508/509) are not > "supported by Wisp628"... > > Not much to do about that, I guess, but is there > a simple way to describe what's special with > these compared to, let's say, the 12F629/675 ? In a word, different programming specifications. There are many differences. For example, the config word location is different. This will require an updated firmware. Right now PICkit 2 is much better in terms of chip support than Wisp628... Regards, Xiaofan

Stef Mientki wrote: {Quote hidden}> > Jan-Erik Soderholm wrote: > >>Hi. >>It says in the Readme file in the XWisp2 distribution >>that the 12-bit PICs (such as 12F508/509) are not >>"supported by Wisp628"... >> >>Not much to do about that, I guess, but is there >>a simple way to describe what's special with >>these compared to, let's say, the 12F629/675 ? >> > > If I read the programming specs of the 12F675, > (which by coincidence I'm doing right now ;-) > and see the schematic of the wisp628, > I don't understand how the wisp628 is able to program a 12F675 .... > ... the 12F675 programming specs state ... > ... to enter programming mode hold data+clock low, no Vdd, > ... rise Vpp, > ... wait >5usec > ... rise Vdd > ... wait >5usec > I don't see a switch in the Vdd line ??? > > cheers, > Stef > Look at the dongle ( further down the web page) .... The circuit below can be inserted between the Wisp628 and the target PIC to solve this problem. Its main function is to short the target PICs power very briefly (a few milliseconds). The diode ensures that the Wisp628 still has power during this brief period.....

> I don't understand how the wisp628 is able to program a 12F675 .... Officially it isn't, at least not without the addition of the extra ('dongle') circuit. In practice the Vdd-before-Vpp sequence will work, unless the /MCLR pin is configured as input. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

Wouter van Ooijen wrote: >> I don't understand how the wisp628 is able to program a 12F675 .... >> > > Officially it isn't, at least not without the addition of the extra > ('dongle') circuit. In practice the Vdd-before-Vpp sequence will work, > unless the /MCLR pin is configured as input. > > sorry Wouter, I didn't read until the end of the page. I had trouble programminging the 12F675 reliable, following the exact specs. It turned out that 5 usec delay between Vpp and Vdd rise wasn't enough and I need 30 usec to program the device reliable. So that's why I'm so interested in the exact specs (knowing there are a lot of errors in the uchip docs ;-) cheers, Stef

Xiaofan Chen wrote : > On 5/23/06, Jan-Erik Soderholm <.....jan-erik.soderholmKILLspam@spam@telia.com> wrote: > > ... is there > > a simple way to describe what's special with > > these compared to, let's say, the 12F629/675 ? > > In a word, different programming specifications. OK, right, I understand that... :-) What I *realy* ment to ask was, if this is only a firmware "issue", or if there is something in the Wisp628 *HW-design* that prevents it from programming 12F5xx ? > Right now PICkit 2 is much better in terms of chip support > than Wisp628... Hm, maybe I should take a closer look at them, in particular the (if any) volume discounts on them... Regards, Jan-Erik.

> It turned out that 5 usec delay between Vpp and Vdd rise wasn't enough > and I need 30 usec to program the device reliable. That might be a spec problem, but are you sure your Vdd rises that fast? IIRC I use a few ms delay. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu

Wouter van Ooijen wrote: >> It turned out that 5 usec delay between Vpp and Vdd rise wasn't enough >> and I need 30 usec to program the device reliable. >> > > That might be a spec problem, but are you sure your Vdd rises that fast? > Vpp rises in less than 1 usec (upto 9V, and then needs about 10 usec to get to 13V) The 1 usec is required by the specs, didn't measure Vdd rise, because couldn't find a relevant spec. > IIRC I use a few ms delay. > Of course that's the trick to be on the safe side, but first I want to find the edges ;-) cheers, Stef

Wouter van Ooijen wrote: >> It turned out that 5 usec delay between Vpp and Vdd rise wasn't enough >> and I need 30 usec to program the device reliable. >> > > That might be a spec problem, but are you sure your Vdd rises that fast? > > IIRC I use a few ms delay. > I discovered that for some PICs the time between VPP & VDD / VDD & VPP needs to be held precisely to reliably acquire Programming Mode. The PIC16LF87/88 and the PICF87/88 have to be held tight under certain settings, such as MCLR\ used as an input and no powerup delay. --Bob > Wouter van Ooijen > > -- ------------------------------------------- > Van Ooijen Technische Informatica: http://www.voti.nl > consultancy, development, PICmicro products > docent Hogeschool van Utrecht: http://www.voti.nl/hvu > > >

On 5/23/06, Bob Axtell <engineerKILLspamcotse.net> wrote: > I discovered that for some PICs the time between VPP & VDD / VDD & VPP > needs to be held precisely > to reliably acquire Programming Mode. The PIC16LF87/88 and the PICF87/88 > have to be held tight under > certain settings, such as MCLR\ used as an input and no powerup delay. > > --Bob I have problems with 16F777 with PICkit 2. 16F767 is okay. It is kind of strange. I think it is also because of the programming mode entry problems. Regards, Xiaofan