I got into AVR chips because they are easy to program, and that has become more and more true over the years with the ever-falling cost of programmers. But it’s pretty easy to make a mistake when burning the fuses on the chips and if you don’t have a proper programmer (my first programmer was a horrifyingly slow self-built DAPA cable) you’ll have a brick on your hands. This little board may be able to help in that situation. I gave the USB µISP a try this week. The half-stick-of-gum-sized board flashes firmware like a champ and includes a rescue pin for when you have clock source problems.
My full review is below. All technical information for the µISP can be found in the User’s guide. The board itself is now available to purchase in the Hackaday Store.
Here it is, used as an In-System Programmer for an ATtiny84 chip. The programmer powers the target and has a switch to change between 3.3v and 5v. An AP2331 seen in the schematic provides over-current and reverse-current protection.
This board was designed by our friend [Nick Sayer] and is based on the USBtiny programmer by [Dick Streefland]. Programming with AVR Dude is fully supported using the programmer argument “usbtiny”. I didn’t need to do anything to gain access to the board. When plugged in via USB it enumerates on my Linux Mint 17 system as: “1781:0c9f Multiple Vendors USBtiny”. There were no problems with permissions (sometimes I need udev rules for USB programmers) as the AVRdude port argument “usb” works.
It ships with a shrouded header for the 6-pin ISP connection as well as the IDC cable which has a key in the plastic housing to ensure the cable is plugged in correctly. I appreciate the silk screen on the back side of the board which identifies each of the six signals. I’m frequently using 6-pin ISP for programming on a breadboard and don’t actually have the pin-header on the target. This allows me to look at the bottom of the board and the bottom of the IDC plug to insert jumper wires quite easily. This is what I did to test out the programmer’s killer feature which is a recovery clock signal.
Recovery Clock
This is a new design of the board as of February 2015. There is a single pin header located in the middle of one long edge of the board. The vast majority of the time you won’t use this, but when you need it you’ll be glad it’s there; it’s a recovery clock signal.
AVR chips have a configurable clock which can be driven using an internal oscillator or an external crystal or clock signal. Because these settings are “burned” into resettable fuses, a chip reset will not fix things if you choose an external source and don’t actually have one. In this case, connect this single pin header to the appropriate pin on your target and you’ll be able to reset the fuses to use the internal oscillator (or choose the appropriate external clock speed if that is the cause of your problems).
There is just a single command-line change needed when using this pin to rescue a chip. Add “-B 250” to enable the appropriate SPI clock timing via AVRdude. Below I scoped the rescue signal and I went through the process of “bricking” and recovering a chip just as an example.
Conclusion and Some Extras
Over all I’m very happy with this programmer. It brings the no-nonsense you expect from a USB ISP programmer and adds in the occasionally necessary clock signal. It doesn’t have high-voltage programming and it can’t be used as a debugger. But I have other tools for that which are a hassle to set up just for ISP and are more bulky. For the beginner this is a great programmer to start with, for the experienced AVR aficionado this is a nice and inexpensive addition to your embedded tools.
As an extra, I really enjoyed watching this video [Nick] made about the production process. He gets full panels of boards with the surface mount components already populated but the firmware hasn’t yet been flashed. His routine uses a pogo-pin adapter to program, but there is a failure on a few of the modules. Turns out that the crystal pins for the on-board ATtiny2313 sometimes bridge during reflow. A quick touch of the iron removes the short and the board fires up just like it should.
Nice product, although this doesn’t appear to offer much more (with the exception of a clock signal output on a pin) over a cheap USBasp that you can buy off of Ebay for a much lower price. I wouldn’t mind seeing one that also has a USB-Serial converter onboard. The pin labeling is a nice touch.
My answer all along for feature additions has been that the 2313 is out of firmware space, but it’s conceivable that a future version might use the 4313 instead (which has twice as much flash space), which would open up new doors.
Would be more of more interest with high voltage programming.
Seconded. I’ve only messed up like 2 AVR chips from messing up the clock fuses, but I regularly squeeze my 8 pin ATTinys for their 6th IO on the Reset pin. It would be so nice to have a programmer that can handle that too (my AVR dragon bit the bullet after 3 faithful years and I’ve been hesitant to get another one…)
The irony was that shortly after I made the first prototypes I actually *did* screw up the fusing on a board I was building (of a different sort). I wound up fusing a chip without a crystal as if it had one. Of course, it went dead. As soon as I figured out what I had done, I recovered it with the recovery clock pin on that prototype.
Just use a fuse resetter:
http://www.simpleavr.com/avr/hvsp-fuse-resetter
The big problem (as I see it) with HVP is that it’s not at all standardized. Seemingly just about every chip has a unique variant on the HVP connections required.
It’d have been a lot easier if HVP really just meant that by putting +12 on the RESET pin you could force it into normal ISP programming mode just like holding RESET low normally does.
Yesssss, every time I had to do an HVSP I would have to get the Dragon’s HVSP port pinout and the AVR chip’s pinout and match up individual wires, so annoying.
Out of curiosity, why didn’t you simply start off with using the 4313? Some quick searches show that the 4313 overall is a bit cheaper than the 2313.
I started off with the Pocket AVR programmer’s design and fixed the “target power leak” problem (lack of a blocking diode on the BUFFEN line) first. What followed after that was the 3.3 / 5 volt power switching, the AP2331 and then the recovery clock. Until recently, it never occurred to me there was a different choice to be made.
Gotcha, thanks for the answer.
Oh, also, check that you’re pricing the 2313A, not the 2313. I think they keep making the latter for folks who *insist* on having *exactly* that part, but they’d rather you have the 2313A. On DigiKey in single-unit quantities cut-tape, the 4313 is about 25¢ more than the 2313A (of course, that’s not how you’d get them if you were making a bunch. I’m just using that pricing for illustration).
Since it is kind of based on the USBtiny I wonder if it has the same bug and cannot flash to chips with >64k flash size?
http://forums.adafruit.com/viewtopic.php?f=20&t=24409
I’m using the latest firmware from Dick’s site: http://dicks.home.xs4all.nl/avr/usbtiny/
If he fixed it somewhere along the way, then it’s fixed in this one. If not, then it’s still outstanding. Assuming that the current kerfuffle with AdaFruit resolves nicely, if the bug is still there, I’ll see if there’s any way it can be reasonably fixed. If it’s a protocol deficiency or something like that, well…
another avr programmer.. ok sure, every engineer has made the mistake of changing the clock selection fuses to internal and temporarily brick the AVR, but he will be vigilant the next time changing fuses. I’m just very disappointed in the quality of Atmel’s tools ! I have a box full of dead Atmel AVRISP’s. Somehow they always bite the dust after a few months. And the flex on my JTAGICE MKII breaks every other month. I’m sick of constantly having to buy new ones.
The AVR Dragon board has had some sudden death issues as well.
Yeah i know. In my experience none of our boards sporting AVR’s have ever had any problems with ESD, yet Atmel’s own programmers seems to die when you look at them askew. Surely they can afford a few extra diodes ?
Who here has at least one dead AVRISP or AVRDRAGON ?
Haven’t got a dead one but 4 working Dragons. Working since about 3 or 4 years.
I read somewehere that there has been a hardware redesign that solved the problem with the charge pump failing with too low USB input voltage (input overcurrent).
Just keep it in the cardboard box and watch your pinout and you’ll be fine.
I use a usbtinyisp that I’ve dragged through hell and high water. It’s spent time in awkward, strained positions and even had breakouts from the ribbon cable made so I could do patch work.
And yet it still runs, even when I let it sit on a shelf for a few months, even when I accidentally drop 12V over the line. It *should* be dead. It isn’t.
How have you managed to kill the Atmel AVRISP (We are talking about right?) As well, if you’re damaging the flat-flex of your jtagICE mkII you’re doing something very wrong — do you yank it off or something?
Yes, I’m sure you must think I abuse my programmers, but I’m quite careful with them in fact, they were used intensively a few years back. They just die after a while, even when you are very careful not to expose them to ESD or mechanically strain them. The flex on my JTAGICE MKII always mechanically fails internally, it will happen after some time, again, even if you’re careful handling it. I’m surprised you think they’re so hard to break, every client, engineer and hobbyist i know has at least one that failed.
Those ISP signals do not even have series terminations! The recovery clock has a bad case of overshoots and undershoots.
I am not sure, but I think maybe that the probe ground wasn’t hooked up when that was taken. On my scope it’s much cleaner.
Yeah, I didn’t use the probe reference.
Good scope probing techniques are important, but there is still issue with the copying/pasting other designs without understanding basic transmission line and terminations. That say a lot about the design that this copied from too. Owing a scope without knowing basic probing techniques nor why that signal is bad… It is one of those face palm moments.
AVR chips have roughly 40 ohms impedance. Stray wire or ribbon cable has a much higher impedance. Without series terminations, this is asking for signal integrity trouble. Even the $3 Chinese USBasp have series termination.
Let’s not forget about the series terminations at the USB input side too…
When I was researching it, I read that the 68 ohm resistors in question were necessary when powering the ATTiny at 5 volts, so I removed them, since the ATTiny in this case is running at 3.3v. I’ll look into it for the next version, but it has been rock solid for me and plenty of others so far. My guess is that the tolerances are quite a bit lower given that it’s a low speed device.
At 5v without the series resistors you’d sink >20ma through the zeners when the oitput is high.
At 3v, as youve noticed, theres no harm in a bit faster slew rate and maybe a bit of ringing from leaving out the resistors.
http://nerdralph.blogspot.ca/2015/01/usb-interfacing-for-avr-microcontrollers.html
https://www.obdev.at/products/vusb/index.html
They have 68 ohms even for 3.3V powered mcu. The series *termination* resistor is not there *just* for current limits and level translations. I suspect that they are there to slow down the rise/fall time.
>Low-speed buffers on hosts and hubs that are attached to USB receptacles must be designed for the 200 pF to 600 pF range. The rise and fall time must be
between 75 ns and 300 ns for any balanced, capacitive test load. In all cases, the edges must be matched to within ±20% to minimize RFI emissions and signal skew.
So… AdaFruit has demanded that I license their VID/PID for the USB µISP.
Read more about it here: http://www.geppettoelectronics.com/2015/05/admiral-ackbar-and-limor-fried.html
UPDATE: So after a lot of reflection, I think I took this to the court of public opinion too early. Adafruit’s licensing terms were *beyond* generous, and part of my initial defensiveness was because I didn’t know that that was going to be the case. My expectations when I got the initial e-mail were apocalyptic, and that’s more my fault than theirs.
I hope you can work something out and still sell your product.
Also, I find it funny that this article was posted just 2 days ago:
http://hackaday.com/2015/05/08/field-trip-hackaday-visits-adafruit-industries/
As the FTDI debacle illustrated: the VID/PID are just numbers, and numbers can’t be copyrighted. Adafruit didn’t buy a license to use the numbers; they bought a license to use USB branding and compliance verbiage in conjunction with those numbers. If you’re not using the USB logo or claiming USB compliance (as it doesn’t seem you are), you can use the numbers as you see fit.
Very poor form on the part of Adafruit. I hope Phillip or Limor will take a personal interest in making right on this issue.
She’s been CC’d on all of the e-mail from their legal department, so I can’t possibly believe she’s not in the loop.
I don’t mind licensing the VID/PIDs from them at all. What I *do* mind is that nowhere is there any suggestion on either AdaFruit’s nor on Dick’s site that there is anything in the firmware that’s encumbered by more than the GPL 2. This is nothing more than a clever trap, and it’s at the very least suspicious that it was sprung the day after the USB µISP appeared on the hackaday store.
I think most of what went down with this was a misunderstanding from both sides. Nick has posted his recollection of the events, Adafruit has clarified the VID/PID licensing issues on their page and granted Nick permission to use them with his uISP. This is reflected in the licensing notice on the bottom of the product page in the Hackaday Store.
Having spoke with both Nick and Phil today, I’m glad that both are happy to have worked this out.
They can’t exactly ask someone to license their VID/PID either as they are in violation of their USB.org agreement.
Any good lawyer(s) should have known that. Only thing they could do is ask not to use their VID.
Which would make any product of the kind worthless, as that VID/PID pair is what avrdude is coded to look for.
I am assuming that a company like AdaFruit has a legally obtained VID which is not in their legal position to sub-license.
The USBasp VID/PID came from V-USB which was purchased from BASCOM which sort of sits in the grey area. Since BASCOM got their VID/PID prior to USB.org changed their agreement not allowing sub-licensing, nothing can be done about that. That would be one of the few that could be used as long as it uses the same protocols.
The VID/PID in AVRDude can also be changed, so it a messy but workable. Who say things are easy?
Well, they have already sub-licensed it to SparkFun, and they are “offering” to sub-license it to me. Go figure.
More detail in this FAQ from the V-USB project, which inspired USBtiny as used in the USBtinyISP:
https://github.com/obdev/v-usb/blob/master/usbdrv/USB-ID-FAQ.txt
Interesting to note their point that software USB implementations like V-USB and USBtiny can’t be strictly compliant with the USP protocol on an electrical level.
nsayer, Adafruit has neither authority nor ability to license these simple 16-bit numbers. You are free to use them under US law.
I don’t mind licensing them at all, assuming the terms are reasonable. My whole point is that nowhere has the need for licensing been communicated. The only mention anywhere in the firmware source suggests otherwise, in fact.
Just checking back in to let eveyone know that the terms were reasonable. Adafruit has given Nick permission to use the VID/PID after they spoke this morning.
Seriously? From what I gathered, there’s no functional reason to need to use that particular PID/VID for avrdude (you can configure it to recongize new VID/PIDs). It’s a matter of common courtesy. Practically, VID/PID makes it easy to identify one piece of hardware from another. As the owners of the VID/PID, adafruit might now have to deal with clones that might have different hardware yet the same VID/PID, in case they ever have firmware updates. Maybe they’ll accidentally brick your hardware when someone uses an Adafruit updater (totally hypothetical, and yes, I know FTDI was deliberate so I’m not trying to make the situation analogous). They have to worry about these things, and at the very least need get some understanding with you. Worse yet, you’re actually selling it now (not just releasing some build-at-your-own-risk design) so there are paying customers who can complain about broken hardware to them now.
I was curious about the VID/PID comment warnings (honestly surprised that that’s all it said), and either there’s a different version of the source code somewhere that I’m missing or you’re GROSSLY misquoting the source code: From Dick’s source code (1.7):
// The USB vendor and device IDs. These values should be unique for
// every distinct device. You can get your own vendor ID from the USB
// Implementers Forum (www.usb.org) if you have a spare $1500 to kill.
// Alternatively, you can buy a small range of device IDs from
// http://www.voti.nl or http://www.mecanique.co.uk, or be naughty and use something
// else, like for instance vendor ID 0x6666, which is registered as
// “Prototype product Vendor ID”.
// The USBtinyISP project (http://www.ladyada.net/make/usbtinyisp/) has
// allocated an official VID/PID pair for USBtiny. Since these IDs are
// supported by avrdude since version 5.5, we use them here as well:
#define USBTINY_VENDOR_ID 0x1781 // USBtinyISP
#define USBTINY_DEVICE_ID 0x0C9F // USBtinyISP
From adafruit’s source code (“2.0”, no idea if this is a different fork or what)
// The USB vendor and device IDs. These values should be unique for
// every distinct device. You can get your own vendor ID from the USB
// Implementers Forum (www.usb.org) if you have a spare $1500 to kill.
// Alternatively, you can buy a small range of device IDs from
// http://www.voti.nl or http://www.mecanique.co.uk, or be naughty and use something
// else, like for instance product ID 0x6666, which is registered as
// “Prototype product Vendor ID”.
#define USBTINY_VENDOR_ID 0x1781 // Adafruit Vendor ID
#define USBTINY_DEVICE_ID 0x0C9F // Adafruit Product ID #1 (from Mechanique)
The entire block of comment before, to me anyway, seems to imply that you should probably not use their vendor ID and that there are easy workarounds to choose something else…and it’s been conveniently not included in the posts? I’m also thinking that Dick didn’t exactly get permission to use their VID/PID, but they haven’t complained because he’s only providing source code and not a product (not even a non-profit kit).
If you look at the little wire example adafruit provided, there’s a warning on the bottom of that page saying that you should not use their VID/PID. And if you check archive.org, it didn’t get added in just the last few days, so I’m pretty sure this isn’t a “trap” but at worst an oversight.
I haven’t even put a full USB product to market yet, and I already knew that VID/PID is one of the first issues I’ve thought about when considering putting a USB product to market… just play nicely, and change the VID/PID to a custom one in future boards. Or if you think you can still work with them, pay some appropriate licensing fee. I know this isn’t how it’s licensed (well, the code, anyway), but c’mon, they paid for their own VID/PID, write up extremely good documentation that applies more or less exactly to your product, and seem to have helping with updates to both avrdude and the usbtinyisp firmware.
This smells bad to me :-/
Considering the cost of VID/PID licence from USB.ORG this is than reasonable. And as the VID idendify Adafruit as vendor they have a reputation to protect too.
For cost asked by usb.org see: http://www.usb.org/developers/vendor/
If you can get a cheaper agreement with Adafruit, good for you.
The problem with an alternative VID/PID is that it won’t be what avrdude is expecting.
And I don’t mind licensing it. What I object to is that nowhere in the firmware source or on either website is there any notice given that there is a commercial encumbrance. In fact, the firmware source suggests rather that AdaFruit kindly donated the VID/PID pair. Maybe that was a misunderstanding on Dick’s part, but given that it’s been that way for years and that AdaFruit used his design, I don’t see how they could be reasonably ignorant of it.
There’s been a further update to the above blog post (http://www.geppettoelectronics.com/2015/05/admiral-ackbar-and-limor-fried.html). If you haven’t read that page before now, you should read it again.
I read that post in its entirety, and it sounds to me like Adafruit is being reasonable and you’re being whiny. They never once asked you to pay money or sign a contract, just to “discuss permission”, and you got offended immediately and accused them of entrapment. Grow up.
How is it not entrapment when there is no suggestion anywhere that licensing is required? In fact, the source code suggested that the VID/PID pair were donated.
Only today has AdaFruit added a notice to their learning site saying that their VID/PID is not free. They have every right to do so, but should have done so years ago.
They may indeed have donated usage of their VID/PID pair to Dick, but that doesn’t mean they also donated it to you.
Adafruit has an interest in knowing what products are using their property (people can flap on about how “you can’t license a number!!” but you know that’s being deliberately ignorant). They didn’t ask you to pay them anything or even stop selling your product. Here’s how it could have gone:
“Hi, we would like to discuss getting permission for you to use our VID/PID.”
“Oh, for sure. I thought they were free to use. Is there a problem?”
“No, not at all, we’d just like you to mention that they’re used with permission from Adafruit Industries, since they are technically our property.”
“Great! I’ll do that! Glad to work with you!”
Deliberately ignorant of what?
0x1781 and 0x0C9F are technically not the property of Adafruit Industries. If I want to produce a commercial device which offers those numbers to avrdude for purposes of interoperability, I am completely legally free to do so.
Can you offer a legal argument to the contrary? I don’t think you can, or I wouldn’t be arguing this point.
(I’ve gotta say that Torrone’s request from the email, “Let’s discuss permission to use the Adafruit USB VID/PID for a product you are selling,” doesn’t strike me as a clear demand or legal threat.)
Entrapment as a legal term means that the party involved are law enforcement officers inducing a crime. Even the movie with the same name said that entrapment only applies to cops and not to criminals… This is just a civil case for contract… http://en.wikipedia.org/wiki/Entrapment
AdaFruit doesn’t have the legal authority of offering a subcontracting, so not even sure what they are doing. At most they can do around the loop hole is letting you have a license to sell or modify “their” product as a reseller or something like that.
Wow Phillip Torrone calls you a jerk, yet in that email he’s the one acting like a jerk!
So after a lot of reflection, I think I took this to the court of public opinion too early. Adafruit’s licensing terms were *beyond* generous, and part of my initial defensiveness was because I didn’t know that that was going to be the case. My expectations when I got the initial e-mail were apocalyptic, and that’s more my fault than theirs.
In any case, I didn’t read the licensing contract from USB.ORG but I doubt that a Licensee can sub-license…
You used to be able to <2009, but no longer. Interesting read (& cheapish PID sub-licensing) http://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&option=com_phpshop&Itemid=1
And I think I was maybe too harsh in calling you whiny. Though I get frustrated by the pervasive attitude in a lot of open-source circles that all rights-holders are somehow the enemies — that if you’re not giving your work away for free, you’re the one being greedy. Guess what: if you put effort into something and want to charge for it, that’s your prerogative.
There are plenty of actual patent trolls and corporate copyright abusers out there to be mad at. No need to get upset with a company that’s doing a tremendous amount of good for open-source just because you can’t use literally everything they make without restriction.
I wasn’t upset that they wanted control over their VID/PID. What had me a little non-linear was that there was no notice I could find anywhere (at the time) that said that their VID/PID was not freely usable. Since then, that’s been corrected, so now there’s no excuse going forward for anyone who makes an ATTiny clone without getting their own VID to not be on notice that they’re going to have to talk to the nice folks (and I’m not being at all sarcastic) at Adafruit about it.
The only remaining conceivable issue is that if you want to use AVRDUDE unmodified with an ATTiny clone, you have to use AdaFruit’s VID/PID. It would be better if there was some alternative way to identify them other than modifying the AVRDUDE configuration (which immediately puts an alternative product at a disadvantage) so that AVRDUDE could see that there was a device (regardless of what it’s VID was) that implemented the ATTiny protocol. Maybe that’s not reasonable to do with the way USB is today. I haven’t done a lot of research to see.
ATmel could write a protocol spec for AVR programming over USB (similar to USBasp or USBtiny) and release it along with a VID/PID pair of their own with the proviso that any use of that VID/PID had to be for a device that properly implemented the protocol. Maybe that wouldn’t square with the USB.org’s licensing, but it would be the best thing for the community, I believe.
Good product, yes. But it stands in a bad place: minimum extra compared to the 4X cheaper ebay versions for when cost is a problem. Way less features than the bare pcb version of the new atmel ice which is 1.5X more expensive, does all micros + debug.
When we will see an open source AVR debugger that uses the debug wire protocol?
Everything about this article and the posts make me soooooo very happy I stay the hell away from AVR…
6 pin in circuit programming? Yuck! I only have to use 4 pins and have never bricked a PIC by just programming the silly things!
I use software tools I paid for of course, but even with the entry fee, it’s paid for itself about a thousand times over in so many ways and I haven’t regretted it. I’d gladly pay for it again, but upgrades are next to nothing, mainly to cover the cost of updated manuals.
That’s the funny thing about this whole DIY / Hacker / Maker culture, I see people spend terrible amounts of money on stupidly useless junk, but flat out refuse to pay for a real programming suite that will work a thousand times better than that “free” arduino crap and other terribly painful to use tool chains.
Spend wisely folks…
Things are not as terrible as you think. Atmel tried to add a “feature” of changing the reset pin to GPIO which once enabled can only put the device in programming mode with a high voltage, kind of like old PICs. The trouble has never been the programmer, but crappy software that would not have that thing disabled by default and asking you to confirm if you really want to disable the reset pin. As most people built programmers without high voltage support they would be unable to fix the chip after this happened.
The other thing that could break your chip is selecting a different kind of oscillator and not providing it. Again, it was due to crappy software that did not first read the fuses and ask you to confirm changes. This does not break the device if you have a programmer with a clock source on it. I have used AVRs for 12 years now and only managed to “break” a single chip by changing the oscillator type, but it was easily fixed.
I have not used the 3rd party sw that people use for 3rd party programmers, but i believe it was fixed in some versions.
Hmm, yes, Atmel chips are universally “stupidly useless junk” and a toolchain that installs with one click and compiles, uploads and executes with a second is “terribly painful to use.”
Sometimes I wonder if the anti-Arduino crowd has ever even touched one of the boards or if they’re just mad that someone bothered to make their obscure field more accessible to the sorts of people they look down on.