Thanks for the advice.
Unfortunately, the wisp won't work for my application.  First, I'm the
programmer, I was given this project to complete, so I have to work with
what I have.  Also, this is just a small part of the project.  I'm building
a gang programmer that will program up to 16 pics for an industrial
application.  So, I've got to reinvent this wheel.

I'm trying the reading the ID though.  Haven't got it to read yet though.

Thanks,

Jim

-----Original Message-----
From: pic microcontroller discussion list
[mailto:PICLIST@MITVMA.MIT.EDU]On Behalf Of Byron A Jeff
Sent: Thursday, March 25, 2004 09:33
To: PICLIST@MITVMA.MIT.EDU
Subject: Re: [PIC:]


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

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