Searching \ for '[PIC] Detecting which device is in a programmer.' 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=programmer
Search entire site for: 'Detecting which device is in a programmer.'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Detecting which device is in a programmer.'
2005\07\07@131639 by Peter Onion

flavicon
face
D'OH !  I've remembered the TAG this time !

I've been looking at the code used by a couple of programmers to detect
the type of PIC that is in the programmer (or on the end of an ICSP
lead).

The general technique seems to be

1) Assume its a 14 bit core and try to read the ID word.
2) If ID word is valid return identified type
3) Assume its a 16 bit core and try to read the ID word.
4) If ID word is valid return identified type
5) return error.

I'm wondering what happens when there is a 16 bit core device in the
programmer, and the programmer tries to talk to it as if it was a 14 bit
core device ?

As far as I can see the risk of an unintentional "table write"
instruction being executed is very low as the 4 bit commands (18F) for
these are "11XX" and none of the 6 bit commands (16F) have the first two
bits as "1" as long as you send "0"s for all "don't care" bits.

Have I missed anything ?

Peter    



2005\07\07@142834 by olin piclist

face picon face
Peter Onion wrote:
> I've been looking at the code used by a couple of programmers to detect
> the type of PIC that is in the programmer (or on the end of an ICSP
> lead).
>
> The general technique seems to be
>
> 1) Assume its a 14 bit core and try to read the ID word.
> 2) If ID word is valid return identified type
> 3) Assume its a 16 bit core and try to read the ID word.
> 4) If ID word is valid return identified type
> 5) return error.

It's more complicated than that, at least the way my programmers do it.
There are issues of different reset sequences (Vpp and Vdd order) and you
left out the PIC 30 altogether.

> I'm wondering what happens when there is a 16 bit core device in the
> programmer, and the programmer tries to talk to it as if it was a 14 bit
> core device ?
>
> As far as I can see the risk of an unintentional "table write"
> instruction being executed is very low as the 4 bit commands (18F) for
> these are "11XX" and none of the 6 bit commands (16F) have the first two
> bits as "1" as long as you send "0"s for all "don't care" bits.

My programmers can sense when the target chip is driving the PGD line, which
is used to avoid nasty situations like this.  It's been a while, but I
remember carefully going over the various command specs to make sure that
checking for one type of PIC wouldn't do a write on another.  Mostly I try
to do a readback from each target type and look for whether the PGD line is
being driven.  If not, I immediately do a reset to abort whatever might be
in progress.

To see the details, download my PIC programmers development software from
http://www.embedinc.com/picprg/sw.htm and look at PICPRG_ID.PAS in the
SOURCE > PICPRG directory.


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

2005\07\07@144317 by Peter Onion

flavicon
face
On Thu, 2005-07-07 at 14:29 -0400, Olin Lathrop wrote:

> To see the details, download my PIC programmers development software from
> http://www.embedinc.com/picprg/sw.htm and look at PICPRG_ID.PAS in the
> SOURCE > PICPRG directory.

I can't as you've only made it available in a windblows ".exe"
:-(

Peter


2005\07\07@144832 by Peter Onion

flavicon
face
On Thu, 2005-07-07 at 14:29 -0400, Olin Lathrop wrote:

> It's more complicated than that, at least the way my programmers do it.
> There are issues of different reset sequences (Vpp and Vdd order) and you
> left out the PIC 30 altogether.

Geeesh...  Can you let me get the 18F working first !  ;-)


> My programmers can sense when the target chip is driving the PGD line,

The what line ?

>  which
> is used to avoid nasty situations like this.  It's been a while, but I
> remember carefully going over the various command specs to make sure that
> checking for one type of PIC wouldn't do a write on another.

Yes that's what I 've done hence my comments about the top two bits in
the 6 bit commands needing to be "0" although they are "don't care" in
the manuals.

Peter

2005\07\07@150713 by Vitaliy

flavicon
face
>> To see the details, download my PIC programmers development software from
>> http://www.embedinc.com/picprg/sw.htm and look at PICPRG_ID.PAS in the
>> SOURCE > PICPRG directory.
>
> I can't as you've only made it available in a windblows ".exe"
> :-(
>
> Peter

You need to download install_picprg_dev.exe under "Development Software."

Regards,

Vitaliy

2005\07\07@152311 by Dave W Turner

picon face
> > I can't as you've only made it available in a windblows ".exe"
> > :-(
> >

If by that you mean you use linux, try wine - it works with quite a
few windows progs.

--

Dave
All us base are belong to you.

2005\07\07@153216 by Wouter van Ooijen

face picon face
> > My programmers can sense when the target chip is driving
> the PGD line,
>
> The what line ?

you can't be serious?

Wouter van Ooijen

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


2005\07\07@153216 by Wouter van Ooijen

face picon face
> I've been looking at the code used by a couple of programmers
> to detect
> the type of PIC that is in the programmer (or on the end of an ICSP
> lead).
>
> The general technique seems to be
>
> 1) Assume its a 14 bit core and try to read the ID word.
> 2) If ID word is valid return identified type
> 3) Assume its a 16 bit core and try to read the ID word.
> 4) If ID word is valid return identified type
> 5) return error.

Looks like you took a close look at Wisp628/XWisp.

Note that XWisp offers the user the option to specify the PIC type, in
which case it will try only the specified type. This is definitely
recommended when you want to read the content of the chip.

Note also that there are flash chips (16c84, 16f84, 10fxxx, 12F509?)
that do not have a device ID at all.

Wouter van Ooijen

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


2005\07\07@160238 by Peter Onion

flavicon
face
On Thu, 2005-07-07 at 21:32 +0200, Wouter van Ooijen wrote:
> > > My programmers can sense when the target chip is driving
> > the PGD line,
> >
> > The what line ?
>
> you can't be serious?

Yes I was :-(   I was looking at the table label "PIN DESCRIPTIONS
(DURING PROGRAMMING)" in the programming specifications for the 16F87XA
and 18FXX2 as I assumed it was the name of one of the signals used in
programming.....  No mention of a signal called "PGD" in those tables.
"CLOCK","DATA","SCLK","SDATA" are mentioned but no "PGD" pin :-(

Now I see from the device pinouts that RB7 is labled as "PGD" as well.
I've never noticed that was what it was called, I always thought of it
as "DATA".  Nice inconsistent naming of pins from Microchip there.....

So....  

Olin, I now understand what you meant by "My programmers can sense when
the target chip is driving the PGD line, which is used to avoid nasty
situations like this."   That's a neat idea.

How do you do that ?  Bias the pin to vcc/2 and use comparators to check
it is being pulled high or low but not floating mid-rail ?

Peter


2005\07\07@162027 by Peter Onion

flavicon
face
On Thu, 2005-07-07 at 21:32 +0200, Wouter van Ooijen wrote:

> Looks like you took a close look at Wisp628/XWisp.

Yes.  I do find the jal hard to follow sometimes though....

I couldn't see how it worked at all until I noticed that
d_0,d_1,d_2,d_3 are infact the same as d20,d19,d18,d17 !

> Note that XWisp offers the user the option to specify the PIC type, in
> which case it will try only the specified type. This is definitely
> recommended when you want to read the content of the chip.

I'm reading Xwisp.py in conjunction with wisp628.jal so I've seen that
is the case.

> Note also that there are flash chips (16c84, 16f84, 10fxxx, 12F509?)
> that do not have a device ID at all.

Yup, I'm on top of that.   The only case I have to deal with is the
18F84 because I have some of them but none of the others.

Peter

2005\07\07@162216 by Dave Tweed

face
flavicon
face
Vitaliy <spam_OUTvitaliyTakeThisOuTspammaksimov.org> wrote:
> Peter wrote:
> > Olin wrote:
> > > To see the details, download my PIC programmers development software
> > > from http://www.embedinc.com/picprg/sw.htm and look at PICPRG_ID.PAS
> > > in the SOURCE > PICPRG directory.
> >
> > I can't as you've only made it available in a windblows ".exe"
> > :-(
>
> You need to download install_picprg_dev.exe under "Development Software."

Treat the .exe file the same as you would a .zip file, and ignore the
self-extracting aspects of it.

-- Dave Tweed

2005\07\07@164940 by Wouter van Ooijen

face picon face
> I couldn't see how it worked at all until I noticed that
> d_0,d_1,d_2,d_3 are infact the same as d20,d19,d18,d17 !

Yeah, maybe not a nice technique. My excuse is that that software is
written to be optimally maintainable by *me*. Which is sure different
from being optimally readble by the rest of the world!

Wouter van Ooijen

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


2005\07\07@165355 by Peter Onion

flavicon
face
On Thu, 2005-07-07 at 16:22 -0400, Dave Tweed wrote:

> Treat the .exe file the same as you would a .zip file, and ignore the
> self-extracting aspects of it.

I never knew you could do that !   Thanks for the VERY USEFUL tip Dave !

Peter



2005\07\07@170113 by olin piclist

face picon face
Peter Onion wrote:
> I can't as you've only made it available in a windblows ".exe"

I have work to get done and don't have time for bucking the standard.  I
guess you're just left out.  Not my problem.


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

2005\07\07@170258 by olin piclist

face picon face
Peter Onion wrote:
>> My programmers can sense when the target chip is driving the PGD
>> line,
>
> The what line ?

I don't understand how you can possible ask this question after reading a
programming spec, but PGD is the serial data line and PGC the serial clock
line for PIC ICSP.


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

2005\07\07@171331 by Peter Onion

flavicon
face
On Thu, 2005-07-07 at 17:01 -0400, Olin Lathrop wrote:
> Peter Onion wrote:
> > I can't as you've only made it available in a windblows ".exe"
>
> I have work to get done and don't have time for bucking the standard.  I
> guess you're just left out.  Not my problem.

Thanks to Dave Tweed's help I've got it unzipped (since all that was in
there was a zip file).

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

2005\07\07@171517 by Peter Onion

flavicon
face
On Thu, 2005-07-07 at 17:02 -0400, Olin Lathrop wrote:

> I don't understand how you can possible ask this question after reading a
> programming spec, but PGD is the serial data line and PGC the serial clock
> line for PIC ICSP.

You need to get an ISP that delivers your mail quicker!  I answered this
over an hour ago.

Peter



2005\07\07@172646 by olin piclist

face picon face
Peter Onion wrote:
> Olin, I now understand what you meant by "My programmers can sense
> when the target chip is driving the PGD line, which is used to avoid
> nasty situations like this."   That's a neat idea.
>
> How do you do that ?  Bias the pin to vcc/2 and use comparators to
> check it is being pulled high or low but not floating mid-rail ?

You can download the EasyProg schematic from
http://www.embedinc.com/easyprog and see for yourself how the PGD line is
handled.  The controller drives it thru a resistor.  It takes on the
controller's value when the target chip is high Z.  The resistor is high
enough that the target chip can overcome it when driving the line.  The
controller firmware drives it both low and high to see if it follows or not.
The ProProg works a little differently.


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

2005\07\07@173518 by olin piclist

face picon face
Peter Onion wrote:
> Thanks to Dave Tweed's help I've got it unzipped (since all that was
> in there was a zip file).

Mostly.  There is also an installation program that runs automatically when
unpacked by the EXE itself.

Anyway, you should now be able to look at SOURCE > PICPRG > PICPRG_ID.PAS to
see the high level logic I use to determine what PIC is out there.


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

2005\07\07@173617 by Peter Onion

flavicon
face
On Thu, 2005-07-07 at 17:26 -0400, Olin Lathrop wrote:

> You can download the EasyProg schematic from
> http://www.embedinc.com/easyprog and see for yourself how the PGD line is
> handled.  The controller drives it thru a resistor.  It takes on the
> controller's value when the target chip is high Z.  The resistor is high
> enough that the target chip can overcome it when driving the line.  The
> controller firmware drives it both low and high to see if it follows or not.

Yup I see how that works now, thanks.

Peter


2005\07\07@173843 by olin piclist

face picon face
Peter Onion wrote:
> You need to get an ISP that delivers your mail quicker!  I answered
> this over an hour ago.

It has to do with sequential order, not speed.  I, and I suspect many
others, process mail sequentially as received.  If I'm gone from the list
for a day or more I might wait to reply to a post until after seeing other
responses, but when I've only been off for a few hours that seems like an
unreasonable hassle to ask for.  This is the nature of email lists, and
shouldn't be any surprise to you.


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

2005\07\07@200705 by Chen Xiao Fan

face
flavicon
face
That is what I did in Linux (just unzip the files). For me I have
another option, just copy the files from the Windows partition
since I have two dual boot machine (Windows XP + Ubuntu 5.04).

The prepic utility works under Linux with Wine (if you have
got MPLAB successfully installed). The pic_read.exe and
pic_prog.exe do not work under wine due to the broken support
of serial communication.

Regards,
Xiaofan

{Original Message removed}

2005\07\08@095302 by Peter Onion

flavicon
face
On Thu, 2005-07-07 at 17:35 -0400, Olin Lathrop wrote:

> Anyway, you should now be able to look at SOURCE > PICPRG > PICPRG_ID.PAS to
> see the high level logic I use to determine what PIC is out there.

Yup that's useful....

I'm now trying to work out something that doesn't seem to be quite clear
in DS39576 the FLASH programming spec for the 18FXX2/XX8 devices.

In the timing diagram for the table read commands (Fig4-1 on page 20),
it isn't clear what sets SDATA back to being an input on the target
device.  It looks like it's the first rising edge on SCLK for the next
4-bit command but I can't see this explicitly stated anywhere.

If this is the case, I think there maybe a bug in Wouter's wisp628 code
which looks like it sets the SDATA line from the programmer to be an
output and sets it's state before raising the SCLK line for the first
time.

Peter





2005\07\08@101705 by Wouter van Ooijen

face picon face
> If this is the case, I think there maybe a bug in Wouter's
> wisp628 code
> which looks like it sets the SDATA line from the programmer to be an
> output and sets it's state before raising the SCLK line for the first
> time.

let me (or the list) know when you reach a verdict :)

Wouter van Ooijen

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


2005\07\08@103218 by Peter Onion

flavicon
face
On Fri, 2005-07-08 at 16:17 +0200, Wouter van Ooijen wrote:
> > If this is the case, I think there maybe a bug in Wouter's
> > wisp628 code
> > which looks like it sets the SDATA line from the programmer to be an
> > output and sets it's state before raising the SCLK line for the first
> > time.
>
> let me (or the list) know when you reach a verdict :)

I think I need to implement Olin's circuit to detect when the target is
driving the PGD line and check to see when it is released.  I've got a
spare PORTC pin I can use.

I've just checked back to the 16F877A manual and it was much more
obvious what happens in that case as if shows the signal going tri-state
after the 14th bit has been sent.

Peter

2005\07\08@151043 by Peter Onion

flavicon
face
On Fri, 2005-07-08 at 15:32 +0100, Peter Onion wrote:

>
> I think I need to implement Olin's circuit to detect when the target is
> driving the PGD line and check to see when it is released.  I've got a
> spare PORTC pin I can use.

I've done this now, and debugged my code so that I'm correctly reading
the ID bytes out of a 18F458.

As I expected from the diagrams, a 16bit target does indeed continue to
drive the PGD pin until the first rising edge of PGC for the next 4 bit
command.  This is in contrast to a 14bit target which returns the PGD
pin to input after it has sent all 14 bits (in bit times 1..14 of the 16
clock cycles).


I've checked your code again Wouter, and I think there is a potential
problem in these three functions.  I've pointed out where I think the
problem is.  After calling target_receive, the target is still driving
PGD as PGC is low. The next time target_send is called (from
target_send_20 for example when reading multiple bytes) at the point
where data_pin_direction is set to output, the target is still driving
the PGD pin !  Now since there are resistors between the programming pic
and the target there probably isn't a problem....

I could be wrong because I havn't actually tried to observe this
happening with a 'scope.

Peter


-- 18-bit PICs: read a single byte, using command cmd
function target_read_byte( byte in cmd ) return byte is
  target_send( cmd, 4 )
  var byte dummy = target_receive( 8 )
  return target_receive( 8 )
end function

procedure target_send(
  byte in data,
  byte in count
) is
  var bit data_bit at data : 0
   
  data_pin_direction = output    <<<----  Problem here I think
  for count loop
     data_pin = data_bit
     clock_pin = on
     data = data >> 1
     fast_pump_cycle
     clock_pin = off
     fast_pump_cycle
  end loop
  pump_cycle
   
end procedure

function target_receive( byte in count ) return byte is
  var byte data
  var bit data_bit at data : 7

  data_pin_direction = input
  for count loop
     clock_pin = on
     fast_pump_cycle
     data = data >> 1
     data_bit = data_pin
     clock_pin = off
     fast_pump_cycle
  end loop
  pump_cycle
       
  return data >> ( 8 - count )
end function



2005\07\08@160526 by Wouter van Ooijen

face picon face
> I've checked your code again Wouter, and I think there is a potential
> problem in these three functions.  I've pointed out where I think the
> problem is.

thanks!

For anyone who doubted: there is an certain advantage in making your
code open (note that full GPL or BSD style openness isn't even
required).

Wouter van Ooijen

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


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