High Voltage AVR Programmer

The most common way of programming AVR microcontrollers is the In System Programming port. That little six-pin header with MOSIs and MISOs coming out of it will program every AVR you’ll ever come across. The ISP does have a downside – fuses. Set your fuses wrong, and without a High Voltage Serial Programmer, your chip is bricked. [Dilshan] designed his own HVSP that’s less expensive than the Atmel STK500 and has a nice GUI app.

Instead of following in the footsteps of the USBtinyISP, [Dilshan] is using a PIC18F as the main microcontroller in the programmer. This chip was chosen because of its built-in USB functionality. Because the High Voltage part of a HVSP operates at 12V, actually providing that voltage needed to be taken into consideration. For this, [Dilshan] is using standard 78xx regulators with an 18V input.

The app to control this programmer does everything you would expect, including all the usual AVRdude commands. A great build, and just what we need to reset the fuses on a few dozen chips we have sitting around.

50 thoughts on “High Voltage AVR Programmer

  1. Oh, I’ll also mention that it’s not too difficult to difficult to make a low-current 5V->12V boost converter for this application. The +12 volts isn’t a power supply for HVP, it’s more of a distinct signal to get the chip to change modes. Generating 10 mA @ 12V would require less than 50 mA @ 5V – not too terrible an added load.

    The result is an HV programmer that would operate on just USB supplied power. What makes the concept difficult, however, is the wide variety of HVP wiring pinouts for the AVR chips. Plus, if you’re talking about SMD devices, you’d need to either make some sort of HVP header available on your board (and there is no standard pinout for that, so it would be necessarily proprietary), or you’d need to resort to “acupuncture programming.” For me, the path of least resistance has been to just swap out and throw away the controller.

    That said, I suspect the incidence of bad fusing on SMD controllers is much lower. People tend to play with fusing more on the breadboard, and SMD controllers tend more to be in final designs, where programming-at-manufacture tends to be scripted so there’s much less opportunity for error.

    1. HVPP needs an insane number of signal pins, one of which tends to be the clock input, so for any design which uses an external clock (which I suspect is the vast majority of SMD based designs), it’s near impossible to use HVPP in-circuit.

      If I may tout my own project, for occasional high voltage programming, it seems to me it’s easiest to use an Arduino with ScratchMonkey: http://microtherion.github.io/ScratchMonkey/index.html

  2. Not to uh… reject this project but uh… PIC?

    At a professional level, I can see this as being a solution but at a hobbyist level? I know very few hobbyists who dabble with AVR also play with PIC (though the reverse seems to not be true). Practically if the 8-bit AVR isn’t going to do the trick most of those guys jump up to AVRs 32-bit line or like me move to ARM.

    PIC isn’t bad, my very first AVR programmer is PIC based. I’m just wondering as to the practicality of this when it seems like the bulk of AVR (ie Arduino-land) people seem to have no interest in the PIC line.

      1. Ah… I see the point now.

        I don’t have a problem soldering SMD after years of trepidation. Except for the fact I keep losing the parts, I find them much easier to solder.

          1. I rarely share either AVR or PIC between projects so I don’t see the real benefit for me. If it was a concern, I would install a socket and use a socketable version.

          2. Bought generic smd breakout boards and keep a few controllers and generic parts around, another useful tip is soldering the microcontrollers in over sized breakouts and use the excessive pins to solder a standard ICSP header

      2. Yep, PIC blows away AVR as far as offering a variety of parts in DIP. Was one of the primary reasons I chose them to start learning MCUs, since I wanted to start from bare chips on an old-fashioned breadboard. I can solder a SMD package just fine, but still favor DIP due to the ease of moving parts to newer projects, upgrading MCUs when a project scope changes, or swapping them for troubleshooting. There’s always SMD-to-DIP adapters, but why bother when a part is available in native DIP? And for those who suggest I’m stuck in the past or have a “handicap” because I still prefer DIP, let’s try a MCU swap and see who finishes first. ;)

    1. I am ditching AVR in favor of the SiLab Universal Bee line for USB. They are cheap enough (on par or cheaper than Microchip) that you don’t care about reusing them. Their “free” development environment seems to be nice enough and their debugger or eval board are $30 range.

      It seems to be a good part is assuming that your soldering skill has kept up to QFP parts and not forever stuck in 1970’s obsoleted DIP world. Not everyone shares that handicap.

      If you really need to breadboard, just make up a few breakout board with 0.1″ headers next time you order a set of PCB. Surfboard or other breakout board vendors probably have something for the package.

    2. Someone who is familiar with AVR microcontrollers needs about a day to get familiar with PIC microcontrollers, and it works both ways. Good thing about PICs is you can get 18F2550 for about 2€, I’m not sure if you can get AVR with native USB 2.0 support for that money.

      1. I tend to disagree, but maybe due to lack of knowledge… I do know to get an AVR running, alls I needs to do is grab a GCC package and a few others, no matter what OS I’m using… but what with PIC? Seems (to me) the *majority* of PIC solutions involve custom closed-source software, written only for Windows, that cost money… That’s more than a turn-off, it’s a huge hindrance turning a day of familiarization with register-conventions into days of setting up a dedicated computer, saving moolah for a dev-environment that only works with PICs, and more. Got no problem with them, otherwise, and agree that the peripheral (and other) options seem quite promising… Every few years I check whether there’s an open-source PIC path, maybe I just don’t know what to search for. (Note that “every few years”, when combined with a moolah-costing dev-package could very-well mean a new version of Windows to deal with, and a new dev-package to buy!)

        At the *coding* level, I think you’re right about familiarization-time. The joys of C :)

        The PIC32’s are somewhat appealing, being based on MIPS, maybe they’re GCC-compatible. OTOH, the learning-curve from an 8-bit MCU to a 32-bit *processor* with virtual-memory, etc… well, for me anyhow, that’s proven to be *significantly* more than a day’s familiarization.

        (…not at all related to the HV-programmer. It is *kinda* funny that this is PIC-based. Props to the author (and others) for being well-versed in both!)

        1. Exactly. The only reason I chose AVR over PIC is avr-gcc, because the PIC-hardware is clearly more diverse in DIP (and therefore easier to pick an IC to fulfill all of your project’s needs). Windows-only software is not an option for me, so it is really a no-brainer unless pic-gcc or similar starts to get more attention.

  3. Or just ditch the AVR altogether and use the much better PIC18F or PICs in general. But I’m afraid you might have to learn some things, which I know is a sin to the AVR / Arduino generation.

    1. If we were meant to learn PIC then the knowege of how to program an Arduino wouldn’t be written into the genes of all of mankind, accessible to us at birth. Clearly since we have to learn nothing to program an AVR using a PIC is a sin.

    2. PIC18 ! Oh heck, why not just use a GPGPU then if you’re going to go for broke and use a huge amount of hardware?

      A PIC12 with two-level deep stack should be enough for anyone.

    3. I wouldn’t say that PIC’s are better than AVR. I find PICs to be a bit more glitchy. That and MPLAB X and the XC8 compiler are infuriating sometimes.

      That said, I use both PIC and AVR on a daily basis.

    4. I started out on PICs, but ended up ditching them for AVRs due to the fact at avr-gcc is quite nice and the Linux-based toolchain is far superior to anything that can be found for free for PIC. I still have my K128 programmer though, just in case I go back. Oh, and I loved the 18F series with USB. It was just the lack of an open source compiler that got me to switch.

      Oh, and I will respond to your flame bait: I have never nor will I ever use an Arduino, but I love AVRs. Don’t go mixing up the two and throwing them into two categories. I acknowledge many people who use Arduino know nothing of how the processor works underneath or what’s going on (they may never directly touch a register), but I am offended by the thought that just because I use AVRs that I am lumped into that category.

      1. I’m the opposite. I started w/ Arduino, then thankfully got a job and started moving into other Atmel products and Freescale. Now I’m slowly inching into PIC, SiLabs, TI (beaglebone, so AM3359), RasPi, and some others just to try it. I personally like the older IDE’s (when you have it configured and a reasonable code base built up) compared to newer ones trying to do way too much and just annoying.

        That being said, none of these platforms mentioned have made an easier bootloader and IDE to work w/ for beginners, so Arduino folks beat pretty much everyone at that. And I’ve replaced my “gaming” time w/ Arduino projects b/c it’s play time.

  4. I have designed a similar HV parallel programmer but I’ve used an ATMEGA16 as the programmer chip with a serial connection to the PC and a Mono framework based GUI utility. Although it is working fine, I haven’t made a proper PCB for it so it looks ugly on a through hole prototyping board :-(

    1. Only 2 posts mentioned the Arduino, and only one bashed it. That post didn’t even bash it that hard, the Arduino isn’t right for everyone. That’s why there are so many micros, and dev boards out there.

      1. That’s the way it is, this thread is particularly well restrained on the bashing so far.

        What’s interesting is that PIC had its time in the sun ala OOPic and I’m sure I remember the Motorola guys bashing it. At least the guys at my University certainly were bashing it while we set up our Quake and Duke Nukem 3D (insert joke here) gaming sessions.

        I went from the 68HC11 (about four months before the board caught fire), wallowed in OOPic land for a while, moved to AVR then Arm and whatever. I hate the Arduino as well but as a platform, not the AVR itself. Just the same as I detest OOPic but not necessarily the PIC.

        The whole cycle will repeat once Arduino is dethroned and something else moves in.

      2. The old 68HC11 is probably one of the first that has a ROM bootloader that let you program the chip with TTL serial input and also a $68.11 (for University program) eval/development board. I made a board with SRAM, ROM, I/O pins and LCD header (wired to the 2MHz multiplex bus).

  5. If i remember correctly from the time i used tinys and megas the only time you really need a high voltage is when you turned the reset pin into a regular pin. And for that, i believe there are quire a few “fuse doctors” around.
    I did make some project with reset disable a while ago and it was a pain to work with. For hobby stuff, just upgrade to a larger micro to have enough pins.

      1. It’s also the case for the newer ones. If fused for a crystal or external clock, and it’s not there, it won’t program.

        There is, however, a workaround. You can apply a square wave to one or other XTAL pin and get it to come up long enough to fuse it back to the internal oscillator.

    1. You wouldn’t need to use PWM – only need a square wave source. I used a Hex inverter e.g. 74HC04 to wire as an oscillator to drive charge 4-5 stages of charge pump. Given the those Vpp requirement usually like 10mA or so, just a Zener diode and a resistor can regulate the output without even needing CPU cycles to regulate.

          1. As an aside, it’s funny they’d rather have two(+!) separate protocols for programming, rather’n, say, using the same ISP protocol with two separate methods of toggling the RESET line. We’re talking, yahknow, like two or three transistors to detect whether the reset-disable fuse is active, then to use a 12V-reset signal with the standard ISP protocol instead of the usual 0V-reset signal… must be something to do with backwards-compatibility.

          2. Don’t do it! Especially if you don’t intent to remove the IC for programming. Friend’s experience: I’ll use the reset as pin and the circuit connected to it will totally be ok with 12V on the reset line…. NOT.

          3. Well, not so much “don’t do it” but realize the full ramifications of it if you intend to do it.

            HVP in situ can be done, but it means insuring that the rest of the circuit both survives and does not interfere with the process. Still, it’s probably a lot more cost effective to, say, replace an ATTinyx5 with an ATTinyx4 if you need more pins.

  6. For non-professionals I really recommend getting an AVR Dragon for about 50 bucks. Programmer and debugger for AVR and AVR32, interfaces including ISP, JTAG, PDI, debugWire aaand HVP / HVSP.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.