Connect with us

Help with circuit(programming pics)

Discussion in 'Electronic Design' started by Jon Slaughter, Oct 28, 2007.

Scroll to continue with content
  1. 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

    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 ;/

  2. 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))

  3. Jamie

    Jamie Guest

    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?
  4. 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).
  5. 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

    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,

    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
  6. Hmm... Microchip does not know the PIC16F817 so I expect it to be a typo.
    PIC16F871 maybe?
    Have a look at:
    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
  7. 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.

  8. 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.
  9. 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
    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
  10. 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

  11. 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
  12. 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?
    Do you have a scope?
  13. Well, I thought that binaries was pretty much available to everyone... 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)).

  14. I checked on an other server 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.

    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:
    | \
    _| \_

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

    PS where is the Vdd switch????
  16. 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?

  17. 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.


    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.

  18. R8, R11, R18, AND R6.
    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.
  19. 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
  20. 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"?
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day