Searching \ for '[PIC]: 16F628 programming strangeness' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=programming
Search entire site for: '16F628 programming strangeness'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: 16F628 programming strangeness'
2004\11\27@093302 by Philip Pemberton

face picon face
Hi,
 I'm still working on the Easyprog firmware for the Wisp628. I've got it
mostly working - I can program various chips repeatedly and reliably.
 The problem is, the PIC16F628 I'm using for testing isn't one of the chips
that gets programmed reliably. If I plug a "fresh" F628 into my breadboard
and wire it up to the Wisp, then apply power, it'll program fine. If I try
and reprogram the F628 again, it will refuse to return a device ID ("Unable
to read the device ID from the target chip") on the second program attempt.
If I remove the chip and re-power it, the same thing happens - "Unable to
read the device ID".
 Here's the interesting bit - if I hook the chip up to a Wisp628 running the
standard firmware (not my easyprog firmware), the chip will program fine,
then work in the Wisp (with Easyprog firmware). Once the Easyprog f/w has
tried to program the chip, the chip is no longer detected by the Easyprog f/w
and has to be "reset" by programming it in the Wisp.

Olin: What's the difference between an "Unable to read the device ID from the
target chip" error and a "No information was found for a PIC with device ID
16383" error?

I'm beginning to think that porting the Easyprog firmware over to the Wisp
may not be as easy as it looks...

I've uploaded the source code to <http://www.philpem.me.uk/epwisp.zip> for
anyone that wants to take a look. It's about 50kbytes in size.

Later.
--
Phil.                              | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB,
spam_OUTphilpemTakeThisOuTspamphilpem.me.uk              | ViewFinder, 10BaseT Ethernet, 2-slice,
http://www.philpem.me.uk/          | 48xCD, ARCINv6c IDE, SCSI
... Always be sincere, even if you don't mean it.
____________________________________________

2004\11\27@100516 by olin_piclist

face picon face
Philip Pemberton wrote:
>   Here's the interesting bit - if I hook the chip up to a Wisp628
> running the standard firmware (not my easyprog firmware), the chip
> will program fine, then work in the Wisp (with Easyprog firmware).
> Once the Easyprog f/w has tried to program the chip, the chip is no
> longer detected by the Easyprog f/w and has to be "reset" by
> programming it in the Wisp.

Is it possible that low voltage programming is getting enabled, and that
your Wisp modification doesn't hold the LVP line low?

> Olin: What's the difference between an "Unable to read the device ID
> from the target chip" error and a "No information was found for a PIC
> with device ID 16383" error?

The first means it knows there was a failure in trying to read the device ID
at all.  This means it went thru all the algorithms it knows about trying to
figure out what kind of chip is out there, and nothing made sense.  This is
mostly determined by when the PGD line should have been driven by the target
chip.

The "No information found..." message means that the chip appeared to repond
as expected by one of the algorithms, but the ID number that it got back
wasn't listed in the ENV/PICPRG.ENV file.  Note that 16383 is 3FFFh.  In
other words, the PGD line was just floating high when the software thought
the target chip was driving it during attempt to read the device ID.

All in all, I think you have an electrical issue with readback.  Are you
allowing enough time for the PGD line to settle and make it thru to the
controller PIC?

I would use a chip that does seem to work correctly and put the programmer
in a loop to constantly read back a known value with both 1s and 0s in it.
Look at the incoming PGD signal on the scope with respect to the outgoing
PGC signal.  Make sure there is sufficient time for it to settle.

I have no idea how the Wisp hardware works, but on the EasyProg there are
two separate pins use on the controller for PGD.  One is for driving PGD,
the other for readback.  Some resistors are used to allow the output pin to
always be driven, whether doing readback or not.  You may need to make sure
the output PGD pin is set to high impedence during readback with different
hardware.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\11\27@120656 by Philip Pemberton

face picon face
In message <010201c4d492$7e90d070$0300a8c0@main>
         .....olin_piclistKILLspamspam@spam@embedinc.com (Olin Lathrop) wrote:

> Is it possible that low voltage programming is getting enabled, and that
> your Wisp modification doesn't hold the LVP line low?

D'oh! I forgot to connect the LVP pull-down on the WISP to the LVP pin on the
PIC. That would probably explain it :-/

[ "Unable to read device ID" error ]
> This is mostly determined by when the PGD line should have been driven by
> the target chip.

In other words, it uses the TDRIVE command (and sert_test_tdrive) to see if
the PIC is driving the PGD line?
That's one other thing to check, I guess.

> All in all, I think you have an electrical issue with readback.  Are you
> allowing enough time for the PGD line to settle and make it thru to the
> controller PIC?

Yep - 5 clock cycles or about 1uS.

> Look at the incoming PGD signal on the scope with respect to the outgoing
> PGC signal.  Make sure there is sufficient time for it to settle.

That's next on the checklist. I'll see if I can figure out how to get my Tek
466 to trigger off the clock. It keeps missing the transition for some odd
reason (probably down to me fouling up a trigger setting or something).

> I have no idea how the Wisp hardware works, but on the EasyProg there are
> two separate pins use on the controller for PGD.  One is for driving PGD,
> the other for readback.

On the Wisp, one pin on the controller does both driving and readback.
There's a 47-ohm resistor between the target connector and the controller
chip. I guess that means that I'm going to have to rewrite TDRIVE.
For some reason my "save a flag depending on the state of the PGD TRIS bit"
code doesn't seem to work in that situation :-/

> You may need to make sure
> the output PGD pin is set to high impedence during readback with different
> hardware.

I've added code to force TRIS to the correct state to all the PGD
manipulation routines - READ, WRITE, PGDHI, PGDLO, PGDREAD, etc. I don't
think that's the problem, but I could be wrong...

Later.
--
Phil.                              | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB,
philpemspamKILLspamphilpem.me.uk              | ViewFinder, 10BaseT Ethernet, 2-slice,
http://www.philpem.me.uk/          | 48xCD, ARCINv6c IDE, SCSI
... There's nothing quite so wonderful as money.
____________________________________________

2004\11\27@125320 by olin_piclist

face picon face
Philip Pemberton wrote:
> D'oh! I forgot to connect the LVP pull-down on the WISP to the LVP
> pin on the PIC. That would probably explain it :-/

Yes, that could explain all your symptoms.

> In other words, it uses the TDRIVE command (and sert_test_tdrive) to
> see if the PIC is driving the PGD line?

Yes.  Sending various readback commands and seeing when the target PIC
responds is how the software distinguishes between the various PIC types
that have totally different programming algorithms.  The basic algorithms
need to be determined before the chip ID has been read.  Unfortunately
Microchip has made this a very messy process.  They deal with it by not
trying to auto-detect the target PIC.  However, I think auto-detection is a
very nice end user feature.

> Yep - 5 clock cycles or about 1uS.

That's not that much, depending on what kind of circuitry is between the
target PIC and the controller PIC.  If it was a 10Kohm resistor, for
example, it probably needs more time than that.  You need to look at this on
a scope.

> On the Wisp, one pin on the controller does both driving and readback.
> There's a 47-ohm resistor between the target connector and the
> controller chip. I guess that means that I'm going to have to rewrite
> TDRIVE.

SERT_TEST_TDRIVE will need to be implemented in a totally different way than
the EasyProg version.  First, you will need to keep the pin an input except
when deliberately transmitting.  47 ohms is so low that in theory both PICs
can be damaged if both are driving the line to opposite levels.  270 ohms
would be much better and it still plenty low enough for fast operation.

All I can think of to do in SERT_TEST_TDRIVE is to start with the line as an
input (this should be your default anyway), measure it, pulse it the
opposite direction for one cycle only, wait a few cycles, then measure it
again.  This makes use of the little capacitance that is unavoidably on this
line.  If its not driven by the target chip, then it will stay the way it
was put by the one cycle pulse - at least for a few cycles.  If it is
driven, then it will revert back quickly.  Pretty ugly, but it should work
and is all I think you can do with the given hardware.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\11\27@162726 by Wouter van Ooijen

face picon face
> Once the
> Easyprog f/w has
> tried to program the chip, the chip is no longer detected by
> the Easyprog f/w
> and has to be "reset" by programming it in the Wisp.

When you program the same code into the chip using the original
firmware, can your Easyprog firmware reporogram the chip?

Could it be an LVP-related problem (does your firmware pull PGM low)?

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


____________________________________________

2004\11\27@190622 by Philip Pemberton

face picon face
In message <000001c4d4c7$9c0c51d0$0b00a8c0@PAARD>
         "Wouter van Ooijen" <.....wouterKILLspamspam.....voti.nl> wrote:

> When you program the same code into the chip using the original
> firmware, can your Easyprog firmware reporogram the chip?

Yes. Well, it can now, anyway.
It seems I forgot to set PGD back into input mode in the TDRIVE command
handler. I've fixed that and also tweaked TDRIVE to work slightly better (it
now checks to see if PGD is low, if it is, it assumes PGD is being driven;
this is the opposite of what the Easyprog firmware does).
I've just finished adding RUN mode switching to the firmware, which brings it
up to Easyprog protocol version 8, and also gives it all the features of the
Wisp628, excluding Serial Passthrough.

There's a new beta up for anyone that wants to play with it - the URL is
<http://www.philpem.me.uk/prg-wisp.hex>. Download to disk, program into a
PIC16F648, then swap the 16F628 on the Wisp628 with the programmed '648.
After installing the chip, the Wisp628 will no longer work with Xwisp,
Xwisp2, Bumblebee, etc.; use the Embed Inc. prog_pic and read_pic tools from
<http://www.embedinc.com/easyprog/>.

I haven't tried programming a 10F202 yet. Jan-Erik - didn't you offer to do
that? :)

Later.
--
Phil.                              | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB,
EraseMEphilpemspam_OUTspamTakeThisOuTphilpem.me.uk              | ViewFinder, 10BaseT Ethernet, 2-slice,
http://www.philpem.me.uk/          | 48xCD, ARCINv6c IDE, SCSI
... Hire the morally handicapped
____________________________________________

2004\11\27@192641 by Philip Pemberton

face picon face
In message <000501c4d4a9$f673eb10$0300a8c0@main>
         olin_piclistspamspam_OUTembedinc.com (Olin Lathrop) wrote:

> Unfortunately Microchip has made this a very messy process.

Point taken. A single, universal "Read device ID word" command would have
been better than a device ID word in the config area.

> They deal with it by not trying to auto-detect the target PIC. However, I
> think auto-detection is a very nice end user feature.

Same here.

BTW, the fault was in TDRIVE. I've rewritten it and the Wisp628 is doing a
very convincing imitation of an Easyprog :)
Just out of curiosity, is there any way you could add an optional command to
the spec that returns, say, a string that identifies the programmer. For
instance, an Easyprog might return "Easyprog", a Wisp might return
"WispE648" - you get the idea. Just a thought :)

Like I said in my reply to Wouter - my latest beta is online at
<http://www.philpem.me.uk/prg-wisp.hex>. Program it into a PIC16F648 (or
16F648A) and have fun :)

Later.
--
Phil.                              | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB,
@spam@philpemKILLspamspamphilpem.me.uk              | ViewFinder, 10BaseT Ethernet, 2-slice,
http://www.philpem.me.uk/          | 48xCD, ARCINv6c IDE, SCSI
... Cogito cogito ergo cogito sum!
____________________________________________

2004\11\28@055756 by Jan-Erik Soderholm

face picon face
Philip Pemberton wrote :

> I haven't tried programming a 10F202 yet. Jan-Erik - didn't
> you offer to do that? :)

Yes, I think I did.
But I must look up the archives to see if I said anything about
*when* I was going to test it... :-) :-)

Anyway, with your latest additions/corrections I'm probably going to
test it "asap". But first I have grab our snowshovel and make sure
that my wife can get the car out from our parking lot. There was another
aprox 10 cm snow this night in addition to the aprox 20 cm we
got yesterday...

Oops, here whe comes... Got to rush !

Regards,
Jan-Erik.
____________________________________________

2004\11\28@091125 by olin_piclist

face picon face
Philip Pemberton wrote:
> I've fixed that and also tweaked TDRIVE to work
> slightly better (it now checks to see if PGD is low, if it is, it
> assumes PGD is being driven;

That is a bad assumption.  If neither chip is driving the line, it could be
just floating low because that was the last level it was driven to.

I think you should pulse PGD opposite of its state for one cycle, then
release it to high impedence again.  If it is not driven, the line
capacitance will keep it where it is for at least a few cycles.  If it is
driven, it should revert back to its original state quickly.

> this is the opposite of what the
> Easyprog firmware does).

The EasyProg firmware uses a completely different scheme.  It uses one pin
to read PGD, and another to drive it.  There is enough resistance in series
with the driving pin so that the target PIC can overcome whatever way the
controller is driving the line.  The TDRIVE logic drives the pin both ways
and checks whether the actual level follows.  If it doesn't, then the target
PIC is driving the line.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\11\28@092656 by olin_piclist

face picon face
Philip Pemberton wrote:
> Just out of curiosity, is there any way you could add an optional
> command to the spec that returns, say, a string that identifies the
> programmer. For instance, an Easyprog might return "Easyprog", a Wisp
> might return "WispE648" - you get the idea. Just a thought :)

I didn't want to burden small implementations with having to cough up an
ASCII string.  The FWINFO2 command is intended to serve that purpose
instead.  This gives each organization that creates firmware its own 8 bit
namespace.  Your organization ID is 2, which means your firmware must return
2 in the ORG byte of the FWINFO command response.  You then get to define
the FWINFO2 value any way you like.

I guess I need to come up with a general means for other oganizations to
supply text names for their FWINFO2 values.  I'll probably do this by
defining a unique environment file for each organization ID.  Right now I'm
trying to make my software support spec version 10.

I definitely appreciate the feedback.  You are the first "outside"
organization creating firmware compatible with the programmer protocol spec,
so some of these issues haven't been woked out completely yet.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\11\28@172431 by olin_piclist

face picon face
> Just out of curiosity, is there any way you could add an optional
> command to the spec that returns, say, a string that identifies the
> programmer. For instance, an Easyprog might return "Easyprog", a Wisp
> might return "WispE648" - you get the idea. Just a thought :)

I just updated the PIC programmer software at
http://www.embedinc.com/picprg/sw.htm and included such a mechanism.

As I said before, I don't want to burden small implementations with sending
out potentially long ASCII strings, so they send a single firmware type ID
byte instead with the FWINFO2 command.  The ORG byte from FWINFO and the ID
byte from FWINFO2 are used together to allow you to provide a text name to
the combination.

I'm not going to go into all the details of the environment file mechanism,
and the message files layered on top of that.  The software now looks for a
message file of the name PICPRG_ORGn.MSG, where N is the 1-254 organization
ID.  Since your organization ID is 2, your message file would be called
PICPRG_ORG2.MSG.  In this message file, the software looks for a message
named IDNAMEn, where N is the firmware type ID returned by FWINFO2.  The
expansion of this message into a single string will be used as the
programmer or firmware name.  This way every organization gets its own file
that won't get clobbered by software releases from other sources, like my
web page.  You do however have to install the file into the ENV directory as
part of the installation process of your software.

This all sounds a lot more complicated than it is.  To see an example,
download and install the latest software, then look in the ENV directory.
The message file PICPRG_ORG1.MSG is for organization 1, which is Embed Inc.
This is an example of how to get type 0 called "EasyProg" and type 1 called
"ProProg".  This file is meant to serve as a template for other
organizations, so I put a bunch of comments at the top.  No, the details of
the message file syntax are not documented anywhere you can get at.  For now
just copy what is there.  Be careful not to alter the leading indentations,
they are significant.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\11\29@020423 by Philip Pemberton

face picon face
In messages <00b301c4d554$23d2c040$0300a8c0@main> and
           <001c01c4d599$06826d20$0300a8c0@main>
         KILLspamolin_piclistKILLspamspamembedinc.com (Olin Lathrop) wrote:

> I think you should pulse PGD opposite of its state for one cycle, then
> release it to high impedence again.  If it is not driven, the line
> capacitance will keep it where it is for at least a few cycles.  If it is
> driven, it should revert back to its original state quickly.

I've just redone the TDRIVE routine to do what you've suggested. It still
works and, I guess, is likely to be a bit more reliable.

> I'm not going to go into all the details of the environment file mechanism,
> and the message files layered on top of that.  The software now looks for a
> message file of the name PICPRG_ORGn.MSG, where N is the 1-254 organization

[snip]

> This all sounds a lot more complicated than it is.  To see an example,
> download and install the latest software, then look in the ENV directory.
> The message file PICPRG_ORG1.MSG is for organization 1, which is Embed Inc.
> This is an example of how to get type 0 called "EasyProg" and type 1 called
> "ProProg".  This file is meant to serve as a template for other
> organizations, so I put a bunch of comments at the top.  No, the details of
> the message file syntax are not documented anywhere you can get at.  For now
> just copy what is there.  Be careful not to alter the leading indentations,
> they are significant.

OK, that was pretty painless. Now I've got a Wisp628 that can program 10F20x
chips reliably, plus other chips to boot. I'll probably make a release
at some point tomorrow.
I see you've also added my vendor ID to the ENV file - thanks.

Later.
--
Phil.                              | Acorn Risc PC600 Mk3, SA202, 64MB, 6GB,
RemoveMEphilpemTakeThisOuTspamphilpem.me.uk              | ViewFinder, 10BaseT Ethernet, 2-slice,
http://www.philpem.me.uk/          | 48xCD, ARCINv6c IDE, SCSI
... Ok, we'll meet the meat.  That's cool!
____________________________________________

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...