On Thu, Mar 25, 2004 at 08:56:55AM -0600, Jim Monteith wrote:
> Hi all,
>
> I need suggestions on icsp a pic using another pic.

Wisp628

>  I have written my own
> icsp program for windows, and have adapted it to run in a pic.

XWISP (or XWISP2) which operates with the Wisp628

>  I've
> captured the programming process on a meter, and everything looks as it
> should.  bits are being clocked out right when they should be, etc.  BUT,
> when the read command is issued, the pic being programming responds with 14
> ones.

Wisp628 already has all of these problems solved.

>
> Also, I've tried just issuing the bulk erase command to see if the commands
> are being received, and it appears that they are not because the pic is not
> erased.

A hint (I'll get back to Wisp628 in a minute)... Never bother trying to program
a PIC if you are not sure of the interface. The best way to test functionality
is to get your programmer to read the Device ID word at 0x2006 for 16F/12F
parts.  It tests several things:

1) That you are actually getting into to programming mode.
2) That you can issue commands as you need the Load Config Word and Addr
   Increment to get to 0x2006
3) That you can properly read the PIC because all parts have non 3fff or 0000
   ID words.
4) Verify that you are reading the correct bits as the ID word is fixed.
5) Doesn't require any writing and finally...
6) Is always valid no matter the chip state (code protected and the like)

It's the gold standard. My picprg2.3 (soon to be 3.01) versions autodetect the
the chip. If that read comes back 0x3fff and a chip is installed, them I'm sure
that something is wrong.

If you are reading all 1's or all 0's back from the PIC then you are not sure
at all if it's responding.

Now back to our Wisp628 programming...

>
> It's like the only command being received is the read command because the
> pic responds to it. Or, is this a fluke thing?

It's not. But the Wisp628 has been heavily tested under a lot of different
conditions. It's stable. There's no need to reinvent the wheel.

>
> Anyway, any advice would be much appreciated.

http://www.voti.nl/wisp628

It solves all of the problems you have listed above.

>  I've tried all timing from
> the minimums in the spec sheet all the way up into the milliseconds with no
> results.

No long cables between the parts right? Also pic programming has no maximum
time. So setup a pushbutton and an LED on your programmer chip and use the PB
to clock through one state at a time. Or.... I think you know where I'm going
next ;-)

>
> The pic I am programming is a 12f675.  I'm using a 16f877a to do the
> programming.

Use Wouter's tool to solve this problem. Then you can go on and solve another.
The Wisp628 is the ticket. No doubt.

Hope this helps,

BAJ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body