Help with circuit(programming pics)

I tried several circuits to program several pics and none work ;/

I'm not sure if its the circuit(most likely) or the software(possible but
probably not... using WinPic and it has worked for me before(although I
could never get it to work with some other chips)).

I uploaded the circuit to alt.binaries.schematics.electronic.

It consists of a several mosfets.

Port VDD(Q2) is simply used to turn on the power to the other mosfets its
linked too.

VDD, Data, Clock, and VPP are all controlled by the parallel ports control
lines(suppose to be open collectors but they have a pullup).

I use 13V so I can turn on the mosfets completely but also it is needed to
programming the pic in high voltage mode. That part of the circuit is the
VPP to PIC VPP(Q1) part. When VPP is high it turns on Q3 which turns off Q
which turns off PIC VPP. When VPP is low it turns Q3 which turns on Q1 and
hence turns on PIC VPP. I invert the line in the software so its active
high.

The two sub circuits after Q2 are just "drivers" for the parallel port. Both
are non-inverting.

To get output from the pic it goes through Pic Data to Data Read(Q5). When
the pic drives Pic Data high, Data Read goes low and vice versa. There is a
slight issue here in that a Status port pin is attached a to Data Read and
it supplies some voltage to the device when it is disconnected. I suppose I
can put a diode here to stop that?

In any case, everything seems to work when driving LEDS but does not work
when trying to program the pic. (I don't use several of the pull down
resistors where it shouldn't matter all that much) I invert the lines
appropriately and test it all using the software and LEDS.

e.g., if I go into winpic and turn on VPP it turns on an led attached to PIC
VPP and the voltage is what it should be. Each pin does what its suppose to.
(which is that it gives me a low voltage when I send a low voltage in the
software and a high when I send a high)

I've spent last 3 days working on this and can't for the life of me figure
out why it won't program. I've tried slowing down the comm speed and also
tried different circuits. I do not have a logic analyzer so I used LED's
and as far as control goes, everything looks fine.

The pics I've tried are PIC16F817, PIC18F2550, and PIC24FJ16GA002. For the
PIC24 I actually used a different circuit since the levels are lower than
the parallel port. I also wrote some software but it also did not work(I
think my circuit had a problem though).

In any case, maybe someone can spot a problem with my circuit?

The idea is

VDD High supplies power,

The three ouputs Data, Clock, and VPP are all just voltage translations with
VPP translating to 13V. I suppose I could have used another mosfet here
instead of the BJT though? I used the BJT because I don't have any P-Ch
Mosfets and an N-channel would require a higher voltage than 13V.

Data Read is for reading the Data pin on the pic and I need to translate
back. The software automatically holds Data high so that this can be
accomplished. Again, this works in the software where I can see that it
reads the data when I manually force PIC Data to be low or high. If theres
any problems chances are its here.

Any ideas?

PS. About 2 years ago I programmed the PIC18F2450 by using a 3-state hex
driver and a bjt. I was able to program the 18F2450 but could not program
the 18F4550. These two devices use the same programming spec so it should
have worked AFAIK. So its possible that the software has a problem but I
doubt it. I can't find the 18F2450 or the hex driver to test it though ;/


Thanks,
Jon

 

I'm not using the serial port but the parallel port.

No I haven't but like I said, it works fine for driving LED's. The whole
reason of using all the mosfets is to get the voltages up to the proper
voltage. The voltages comming out of my parallel port are about 4V. This is
why I use an external power supply with 5V and 13V(or whatever as I can vary
it. Actually it needs to be about 10-12V for the pic.


Again, I'm using the parallel port instead of the serial port. (not sure if
I mentioned that) and all the voltages on the pin's of the pic are correct
and within spec. (again, that is the whole point of using the circuit
instead of just connecting the parallel port pins straight up to the
pic(specially since some pics require ~ 2.5V or 3.3V))

Jon

 

You may want to check the condition of your serial port.

If you're using a USB-232 converter, that could be your first problem.

they don't work very well.
Also, Voltage levels in many cases are not high enough to drive these
circuits properly.
Originally, most RS-232 ports gave you a nice level output, in the
range of 8 volts and up. now days, they keep dropping the voltages
because these new engineers keep insisting there was never a standard
for voltage levels which is bull crap. It's more marketing to make
cheaper products that operate on the edge to save a few cents.

have you tried a different computer and port?

 

Some suggestions:
On the par port always use separate routines to set or read a bit,
never set 2 bits at the same time.
Always use read-modify-write, or at least a variable that holds the current port states.
Make sure no other driver accesses the par port (printer?).

Make sure you got the memory areas correct for each pic.
Make sure you mask correctly for word width, for example 0x3fff.
Before programming it send command erase ID and configuration (fuses).
Always run a verify if not read protected.

Has been a while since I wrote pic prog stuff, but this is sort of important.

Also make sure you do not send data too fast...
Modern computers are very fast, and you will need delay loops.

I cannot seem to access a.b.s.e right now, this server does not have it,
and I dunno where my list of the old servers is (on some disk).

 

I used software that I know works at least for some pics and it is a very
popular programmer. It does everythign you say so thats not the
problem(assuming I trust it... I do not know what it is actually doing but
like I said, its popular and I know it worked on one pic I did a long time
ago).

It would be nice to rule out the software though... if anyone has a logic
analyzer they could check it out for me Almost all the pics are
programmed in a similar fashion but I doubt the software has it wrong... on
the other hand I can't see what is wrong with my circuit... but chances are
thats there the problem is. (and like I said, it's most likely with the
reading of the pic)

I've tried programming it at different speeds and everything I could think
of but nothing. I have no idea where the problem is which really sucks. A
logic analyzer would come in handy in seeing if its a problem with the
circuit but I don't have one. As far as I know the pic's could be
dead(highly unlikely) and there would be no way for me to know ;/

If your interested in helping you might try taking a look at winpic,

http://freenet-homepage.de/dl4yhf/winpicpr.html

Again, I seriously doubt there are any problems with the software and I know
the circuit is working for the most part but I cannot figure out whats wrong
;/

 

Hmm... Microchip does not know the PIC16F817 so I expect it to be a typo.
PIC16F871 maybe?
Have a look at:
http://www.oshonsoft.com/picprog.html
Harware design and software for programming several types of PICs, including
PIC16F871 and PIC 18F2550.

As for your own experiments I guess it to be timing problems. Not only in
pulse length but also in rise and fall-times of the edges. Too fast maybe as
bad as too slow. Very hard to find out without a logic analyser or at least
a multichannel o'scope.


petrus bitbyter

 

I used to use the FPP and a homemade PIC Programmer Pro. But gave up cause I needed ICD capabilities.
I use Mchips ICD2 now. You should look into it, only ~$200.
Edge transitions on the port can cause problems, but I don't deal with the issue anymore.

Cheers

 

Oops. Its the 917.

Well, I kinda want to know why my circuit won't work.

Why would being to slow be a problem? The PIC's can accept about a 5Mhz
signal so I seriously doubt I'm going to fast. The parallel port is only
running about 50khz max. I figure slowing it down would only help rather
than hurt.

The pic programmer from that site is very similar to what I used a long time
ago except I didn't use any regulators because I had a bench supply.

 

I've recently posted schematics for a PICkit 2 compatible kit with
18F1320 Tutor I sell called Junebug, also the ICD2 Inchworm schematics
and instructions can be found on my site at www.blueroomelectronics.com
Most JDM and parallel port type programmers don't work with fast
machines or modern operating systems like XP or Vista.
The Junebug is the way to go IMHO, it's USB based, fast and is
supported under MPLAB 7.62 (which supports both programming and
debugging most 16F & 18F PICs) It works, is easy to build and very
reliable.

 

I know it can be fun, but seriously, don't bother making your own
programmer, it's not worth the grief. Spend $100 and buy a real one
that is already fully debugged and guaranteed to work.

The last thing you want when programming micros is to be left
wondering whether it's your programmer at fault or your own code.

BTW, the parallel port is a notoriously finicky beast to use. You
might get it working on your machine only to have it fail on another
machine.

Dave.

 

Jesus christ!! Can anyone actually look at the circuit instead of saying its
a waste of time? I know its better to buy one but I want to know if the
circuit itself is bad or not.

Also, almost all programmers do not support the newer PIC24's so its a waste
since thats what I want to use. I'd rather be able to program a PIC myself
since it shouldn't be that hard(since I have the software to do it).

I'm much more interested in what might be wrong with my circuit than
actually programming a pic at this point in time. If that wasn't the case I
would have already brought a programmer such as the pickit2.

I also know that most programmers use a pic as a proxy to program instead of
the parallel port. Again, at this point in time I'm not interested in the
various methods of programming pics and what is better or not but only in
why my method isn't working(because it's more about learning than about
doing).

 

If you could post it to a normal site, and not to the hardly availabe binary groups.
But if your LEDs go on and off as they should, why should it be wrong?
Decoupling?
Do you have a scope?

 

Well, I thought that binaries was pretty much available to everyone...


http://i24.tinypic.com/vxhvgx.jpg
http://server6.theimagehosting.com/image.php?img=Schematic Prints.jpg&album=0&fullsize=1

The pic is the 917 and not the 817. Not that it really matters much.

I have a scope but unfortunately it uses the parallel port(its one of those
crappy velleman pc scopes... a big mistake to buy but thats all I have).

What do you mean by decoupling? What is there to decouple?

I imagine the circuit works except that there is an issue with reading from
the pic. (even though it works manually when I short the PIC data
pin(actually there is a resistor in there from the PIC data side so that
gounding the pic data pin doesn't cause a short on the power supply)

I'll play around with it some more and see what I can come up with but
hopefully someone will spot the flaw so I don't waste to much more time on
it. (I want to know what is wrong with it because as far as I can tell it
should work which means either I don't understand something critical or I'm
just missing something simple(in either case I want to know)).


Thanks,
Jon

 

I checked on an other server news.isu.edu.tw and it had the binaries but only upto 8 october....
Lost of newsservers no longer carry binaries to reduce bandwith.
Web-2 is taking obver lots of tha tpicture stuff, videos...

Got it.
Some remarks, your 100k source resistors are way to high for a fast pull down.
(PIC-data and PIC-clock).
I do not understand you pre-occupation with MOSFETS
What MOSFET? Are you sure that the clock and data output levels are the same as the PIC supply?
Same for PIC Vpp, and I *think* I had a decoupling cap from Vdd to ground,
also requiring lower pull-down (say source) resistors in your case to get good fall times.

Oops.
Next a scope project perhaps.
Get an old analog one for little money.
10 MHz should be enough for things like this.

OK lemme see my own programmer... Yes, 100nF from Vdd to ground,.
!MCLR is pulled down by a NPN and has 2k2 to the prog voltage.

Your signals will now go low like this:
---
| \
_| \_


[A

 

On a sunny day (Mon, 29 Oct 2007 17:22:43 GMT) it happened Jan Panteltje

PS where is the Vdd switch????

 

OK, my error, top left.
May I suggest you replace all the drain 1k resistors by wires,
and replace the source 100k and 1M reistors by say 4k7.
If those 1k drain resistros are some short circuit protection,
then why not put 75 Ohms in the drain of Q2 for example?

 

I assume you mean R8, R11, and R18? I don't see how they can affect the
speed. Are you saying that basically the resistors act with internal
capacitance(in the pic part) so that it forms an RC circuit?

I used that high because I wanted to limit the current when the pic was on.
I guess that might be a bad idea? What kinda values should I be using? 1k?

I used mosfets because they seem like a much better choice than BJT's? What
else could I use? (I'm looking at a discrete solution here because I want
to have more control and it needs to be robust because there is a wide
difference in voltage levels between different pic families).


(the mosfets I'm using are 2N7000)

Well, I was hoping once I get the pic programmer done I could build me a
scope. The velleman scope is a POS. I figured that because its pc based I
could have keep a history of the signal and hence use it sorta like a logic
analyzer but the software does not keep the data in a history buffer. You
can only scoll back a little ways(dependent on the sampling rate). Shit, I
have 1GB of memory and surely it could keep several seconds of the signal
and let me scroll.

It also claims to be 50mhz but I somehow doubt that. I kinda stopped looking
for analog scopes because most are over priced and those few that show up on
ebay that look like good deals are probably not.

I think it might be fun to try and make my own scope though but I need to
get this pic stuff out the way. (well, I have some other projects I need to
do before that)

(I sorta want a scope that will do at least 100mhz and 2-4 channels)

? I added 4uF bypass cap on the power pins of the chip.

[A?


So maybe the circuit is not the issuing but the timing? I figured that since
I'm using mosfets and the pic uses schmitt trigers that it shouldn't matter
all that much? Specially since I'm not sending data very fast. (its rated
for max 5mhz and I'm sending about 1/100th of that(actually, its probably
more like 1/1000). I'm not really trying to maximum speed here.

Once I'm able to program a pic(well, any pic) with the parallel port I'll
either buy me a pic programmer or use another pic to program it and use USB
for the pc interface. I just need to understand why my circuit isn't
working for the reasons I gave before.

Thanks,
Jon

 

R8, R11, R18, AND R6.

Yep.
There is charge,m and to get the voltage down it needs to be removed.
If it goes down slow, then the next pulse may have started before the voltage
is below logic zero threshold, also there are rise and fall times specified
by Microchip, although I would have dto look, but it is in any PIC dataheet.

Well, BJT works just as fine, have only a few hundred milivolt drop when on.

Yes that should work with a 2.1 V treshold.

There was a recent discussion here about scopes, maybe you have read it...

So with 4uF on the chip, and 100k to ground (R8) rc = 4 10^-6 x 10^5 = .4 seconds.
But I hope you switch Vdd, and if so, the soft will have to wait until
the 4uF is charged Via Q2? before it does anything, well tha tis just an extra
power spike, decoupling with 100nF works just fine.
And the 4uF is tantalum? else a 100nF poly cheaper.

Look up rise and fall time specs for your PIC
For going low, 100k in say 50 pF = 5x10^-11 x 10^5 = 5x10^-6 is already 5uS.
I would think nanoseconds are specified.

 

Yeah, they are just there for limiting. I don't know what I used in the
circuit when I actually built it or if I used them at all.

If I remember correctly the mosfets have capacitance which do effect the
speed so those resistors are not necessarily good at high speed(I think this
is what your getting at). But If thats the case I can't see why it really
matters when using such a low communication speed in the first place. Sure I
might lengthen the rise and fall times but it shouldn't matter at such a low
speed?

 

That might be the problem. The datasheet doesn't have any max rise and fall
times but only min delays. This is why I figured that it shouldn't matter
because the delays only basically determine the max transfer speed... and
I'm well below that. It could be causing the problems though. I was trying
to limit the power used to program as its already 20mA. (the pic is suppose
to draw about 10mA max)

I also have to worry about limiting the current to the parallel port as I
don't want to burn it up but I guess this doesn't have anything to do with
the pull downs after the mosfets(R8, R11, etc...).

Since I have to use a high voltage anyways the mosfets work well and get me
within about 5mV within the lower power supply so its not big deal and
probably work better than BJT's in this case?

I have about 7V to work with so thats why I chose them.

I'm not sure how long the software waits. That could be a problem too. The
specs for the Pic24 recommend 10uF on the power pins and I just had 4uF
tantalums so thats what I used.

In the programming spec it doesn't mention any except for MCLR it has max
1.0us. All others are minimum times or just delays.

Your probably right though in that those resistors are slowing down
everything to much. I didn't take that into account when I was making it and
just used pull downs that were large enough to reduce the current. I
probably over did it.

Hopefully thats all thats wrong with it though. Does the idea look right to
you though? I mean, its pretty simple so it should work in "theory"?