Carlos A. Marcano V. wrote :

> Well, I think that it is working because Xwisp and Xwisp2 
> when using the "go" parameter they erase first, write program,
> check and finally put the target in run mode. Just my guess.

I don't follow here...

*If* you have chip that has problem with re-programmiong if
int-MCLR is enabled (like the 12F629/675), I don't see how it
can be erased, since you have to be able to put the chip in
"programming mode" no matter what you'd like to do with it, not ?

Or is an "erase-only" operation less demanding on the access to
the chip ? Such as that you don't have to read the device ID bits
(or something) ?

> By the way, I have tested with a 16F88 also, using internal 
> oscillator at 8 MHz, and RA5-/MCLR-VPP pin function as /MCLR...

If you have *external* MCLR enabled, you'll never have any
problem, AFAIK, since the Wisp628 can hold the PIC in reset
(non-running) state right up to Vpp is supplied. I guess that
that is true for any chip (?).

> and works fine with my Wisp628 (with the shorter cable)
> and using XWisp and XWisp2 softwares.

And the F88 was a less good exemple, since, AFAIK, it doesn't
show this problem (at least not when I tested reasently) no
matter how MCLR was configured (using Wouters blink-a-LED
programs, that *does* lock up a 12F chip...)

Jan-Erik.



-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist