Trying to make my own USBTiny

Go To Last Post
25 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, this is probably above my skill level, really, but it looked fun. I have a Sparkfun USBTiny. It works. I made an attachment for it which has a pair of ZIF sockets and is wired up to support atmega328s in one of them, and the other has one set of pins for an attiny85, and one for an attiny84, so I can program any of those using the USBtiny. This also works.

 

I got the idea that if I had a USB header lying around (I do) and an attiny84 lying around (yup!), I could make a single board which contained both the programmer and the ZIF sockets, and where I wasn't holding the programmer-itself to plug it into a USB port. Sparkfun makes schematics available: https://www.sparkfun.com/product... (see the Documents tab; they include Eagle files.)

 

 

My schematic may be misleading because I was trying to use the board layout stuff to sketch out where I wanted things, so for instance, I don't think the schematic shows the right parts for the zener diodes, but I am in fact using 3.3V zener diodes.

 

So, where I'm at: The device doesn't get detected successfully by my computer as a USB device. It sort of starts to, but does not succeed:

 

[1739368.405665] usb 1-1: new low-speed USB device number 78 using xhci_hcd
[1739368.557890] usb 1-1: New USB device found, idVendor=1781, idProduct=0c9f
[1739368.557895] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
[1739368.557898] usb 1-1: Product: FabISP
[1739397.268827] usb 1-1: USB disconnect, device number 78
[1739430.373732] usb 1-1: new low-speed USB device number 79 using xhci_hcd
[1739430.501883] usb 1-1: device descriptor read/64, error -71
[1739430.737630] usb 1-1: device descriptor read/64, error -71

Error -71 is sometimes a result of, for instance, using a charging cable rather than a data cable, but I've checked with a couple of cables and that's not the problem.

 

The vendor/product IDs are the values I expect for the device, so we're getting as far in the negotiation process as that. Replacing the firmware with a quickie arduino sketch that flashes some of the LEDs confirms that it does seem to be using the crystal, and running at the expected speed.

 

Unfortunately, that's about the limit of my experience/expertise. I don't have (I think) any suitable hardware for any kind of on-chip debugging. I have source for the USBTiny firmware, but don't know enough about it to diagnose it much. I was a bit surprised by the way this design handles the USB D+/D- lines; they're nominally 3.3V, so it's just using the chip's normal 5V lines and 3.3V zener diodes to pretend to be 3.3V. I would think this was sort of crazy-sounding, but empirically it works for the other model.

 

 

I don't think that the LEDs I added to the design are relevant, because my existing USBtiny addon board does the same thing, providing LED indicators of the five non-ground pins on the ISP header.

 

If I use the existing USBtiny, and connect its ISP header pins to the new board, avrdude can use it to talk to a chip in one of the ZIF sockets, so I'm pretty sure that the problem has to be something to do with the firmware or the USB wiring hookup. (More importantly, the ZIF sockets don't become relevant until the device is "up" enough to talk over USB.) The prebuilt firmware appears to be for an attiny84 at 16MHz. This slightly surprised me, as prior USBTiny designs were 12MHz, and there's one comment left in the code about 6 cycles being 0.5 microseconds, but empirically, the premade USBTiny has a metal bit labeled "16.000" that appears to be next to two capacitors, and it works. I haven't tried to rebuild the firmware, but I probably should, it just seems unlikely to result in differences.

 

 

Mostly looking for tips, suggestions, etc. I have done reasonably obvious things (check that all the points that are supposed to be wired together have continuity, and that none of them have continuity to any of the other networks). (Good thing, too, as one of the ground wires was intermittent-at-best and would definitely have caused problems.)

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mostly looking for tips, suggestions, etc. 

 

Point your leds to the right, not left---current flows to the right if at all possible..

Don't draw 4-way connections---creates a miscommunication hazard that is long-lasting.

Your LED will likely keep you in reset without a strong pullup (that may arm-wrestle the programmer).

 

D1 &  D2 should use the zener symbol

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sat. Oct 31, 2020 - 09:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was unable to find a part in my parts inventory which (1) used the zener symbol, (2) wasn't SMD. I don't know why, and I am not familiar with Eagle very much.

 

When you say "4-way connections", what does that refer to?

 

 

 

 

I don't understand what you are saying about the LED. For target chips (the ones being programmed), there's no pull-up, but the reset pin is one of the output pins on the attiny84. I would assume it would be able to sustain a reasonable voltage even with a 2.2mA or so current coming off it? (I know I have that number somewhat wrong but it should be at least close for a 2.2K resistor on 5V). The attiny84 that runs the board has a 10k pullup, but there's no LED on its reset pin -- its reset and the other resets are not connected.

 

I did find one note in the comments for the code in the USB driver that, if using a 16MHz crystal, you have to have very exact timing, and must use a crystal -- not a resonator or something else -- with <2000ppm of error. I have a crystal, but I do not have immediately handy a way to measure the actual clock rate it's producing exactly. The comments also say that there's much broader tolerances at 12MHz (about 1%), so I'm wondering whether I should switch to 12MHz (and rebuild the firmware appropriately).

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The isp connector jp3 has the pins backwards, the odd numbered pins should be on the left, even on the right!

zip up your project folder and upload it, another freak may help you troubleshoot it.

what fuse settings are you using?  Did you clear the clock /8 fuse?

 

jim

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fuse settings are L:FF H:DF. I think that does indeed mean the /8 fuse is cleared.

 

I don't really have a "project folder"? I have a schematic, and a "board" (which is irrelevant as I'm not actually using it, it was just a scratchpad for sketching out placements). The source code is just the Sparkfun driver for the usbtiny, I haven't changed anything there.

 

 

I have an oscilloscope somewhere around here, and I think I'm gonna try to figure out how to use it (mostly "how to get the software for it installed") to find out what actual frequency I'm getting from that crystal -- that seems the most obvious thing to be flaky of the things I have any way to look at.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What firmware are you using?   The stock usbtiny firmware is for the t2313, not the t84.  I don't see any firmware in the sparkfun repo.

https://github.com/sparkfun/Tiny...

Charles Lohr has a version for the t44:

https://github.com/cnlohr/tinyis...

 

The t84 has a very stable RC oscillator, and will work fine if you tune it to the SoF keepalive pulses.  I don't think you'll find a better or smaller version than one I recently wrote.

https://github.com/nerdralph/mic...

 

There's lots of reports of people having problem with the zeners; sometimes the capacitance is too high, or sometimes the reverse voltage is too low at the 1-2mA you'll get with a 1.5k pullup to 5V.  I always run my targets at 3V3.  Sometimes I don't even use a regulator, just a red LED in series with 5V to drop the voltage.

 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using the firmware from https://www.sparkfun.com/product..., the "Firmware" download on that page:

 

http://cdn.sparkfun.com/datashee...

 

The provided Makefile defaults to attiny84, and the chip on the board is an attiny84.

 

It turns out that, while I do have a sort-of scope, it's a 20MHz scope, so I can't do much with it to confirm a high-speed clock.

 

 

 

The thing about tuning the oscillator to the keepalive pulses is basically just a series of words which I individually know, but I have no idea what this would mean, how I would do it, or what the result of doing it would be...

 

I can tell that something worked at all because the programmed-in USB ID shows up on the Linux side, so the machine's exchanged any data at all with it, but then Something doesn't work.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

I don't understand what you are saying about the LED. For target chips (the ones being programmed)

Eh??  you know the reset needs to be high for the chip to run (hence a pullup)...the led will be a strong pulldown, and undermine the pullup, either outright resetting, or borderline.

 

Your ISP is correct number-wise, just double check physically the PCB traces, since physical numbering or mirroring can vary-- it needs to physically end up like this.  The schematic symbol can have the pin numbers moved all over, for example an AVR with 20 pins on one side & 24 on the other. 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sat. Oct 31, 2020 - 11:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Don't draw 4 way connection..is there a connection?  Maybe, maybe not..is your technician going to wire your circuit of 100 chips & connections the wrong way?  When will you find out things are working very strangely?  It can cause some extreley odd problems.

With 3-way connections there is no doubt.

 

Who told you to draw a 4-way connection? 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sun. Nov 1, 2020 - 12:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No one specifically told me to draw a 4-way connection, I was just drawing lines to ground and it happened. In my defense, the junctions in the USB wiring part of the schematic were there in the original I started with. This may be why I didn't worry about them.

 

 

Double-checked, the actual on-board ISP does indeed have the expected layout (VCC is in top-right position, or lower-left if I hold the board upside down).

 

About the reset line: Yes, I know that reset needs to be high for the chip to run. Again, the programmer-chip reset line hasn't got an LED, it's just the target chip that has the LED. If I hook this board up to the usbtiny I have pre-made, it can program chips just fine -- the LED doesn't draw even close to enough to keep the controller from keeping the line at 5V. For the controller on this board, there's no LED on the reset line, just a 10k pullup, and that seems to be working fine.

 

I did some measuring, and I've noticed that on the working usbtiny, the default value of D- when idle is about 2.7V, on mine it's about 2.0V. Since I think the cutoff for signal in a 3.3V signal is frequently around 2.2V to 2.4V, I think that would be enough to break it. I haven't figured out *why* that's happening. So far as I know, the schematic correctly describes the actual wiring I ended up with for this, and apart from different specific-parts, it should be equivalent to what's in the other one. But 2.0V seems weird -- that's outside the range of values I was expecting to see. Documentation elsewhere suggests that the approximate cutoff for USB voltage should be 2.8V, so 2.7V might be a little low but still work, but 2.0V is probably too low. Assuming it's actually supposed to be in the high state. Gonna have to experiment more to figure out what's up here.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 Again, the programmer-chip reset line hasn't got an LED, it's just the target chip that has the LE

Not sure I buy your explain...it is hooked to some chip's reset, yeah?  It will try to pull that reset away from Vcc (towards low), unless it is pulled up.  You don't want it to be borderline reset...you'd like the pin to be at VCC or therebouts.....at least you are aware.

 

Are you sure the USB is not pulsating at all?  Unless you use a scope, you don't say.  A multimeter could give a misread if there as any pulses ongoing.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sun. Nov 1, 2020 - 02:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The LED is hooked up to the pin used to hold the reset pin high or low on the chip being programmed. I've programmed chips with it wired up, it doesn't seem to do anything. Yes, when the programmer is programming a chip, it holds reset high so it can program the chip, and the LED is on. That's why it's there.

 

An EE-sort I know has informed me that the most likely explanation is that "3.3V zener diode" includes a vast array of things, and i should be looking at izk values probably, and/or just using a much smaller zener diode, because the huge chunky 1W-rated ones I got may be "leaking" more current than the circuit otherwise involves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, when the programmer is programming a chip, it holds reset high so it can program the chip

I think you are headed for Niagara Falls.  

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't get it. The white LED part of this is the part that has been working flawlessly in the previous design for months. Basically, imagine the sparkfun "tiny AVR" programmer I linked above. Now imagine making a separate board with an ISP header, two ZIF sockets, a crystal, and the five LEDs on it. That works fine, and has for months, and I've used it for a bunch of chips. Signal LEDs are usually pretty harmless as long as you have enough resistance to keep them from mattering much to the signal.

 

 

This is that, only instead of using their prebuilt programmer, I recreated that circuit. The LEDs are, I'm pretty sure, irrelevant. There's no way an LED with a 2.2k resistor is going to keep an attiny84 from holding a reset pin high. There's no "pull-up" involved; the reset pin is being driven directly by the MCU, and it can handle 40mA of current, and even ignoring the voltage drop, the LED should be using about 2.3mA of current.

 

So, yes, I'm pretty sure the LED isn't a factor. The reset pin on the target chip doesn't need to draw a lot of current, it just needs to be held high, and the MCU has no trouble keeping a pin's output at 5V even while running a small LED at a couple of mA.

 

After talking more with the EE buddy, I've tentatively concluded that the most likely issue is that a casual view of a zener diode is "caps voltage at its rating", but the actual behavior is a lot more nuanced than "do nothing at all until voltage hits this rating, then suddenly cut it off there"; unless it's actually carrying a significant amount of current, it's going to cap the voltage significantly lower than that rating. And the largeish 3.3V zener I got because I didn't know about that looks like it would take about 240mA to do that, failing which it will keep the voltage significantly under 3.3V. (And a 1.5k resistor to a 3.3V zener diode is actually going to be passing significantly under 5mA.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, when the programmer is programming a chip, it holds reset high so it can program the chip

I think you are confused from something along the way.  Reset needs to be held LOW to program the chip. 

 

from AVR910 ISP app note: To enter and stay in Serial Programming mode, the AVR microcontroller reset line has to be kept active (low).

 There's no "pull-up" involved; the reset pin is being driven directly by the MCU, and it can handle 40mA of current, and even ignoring the voltage drop, the LED should be using about 2.3mA of current.

That's better then, though this is the first time you are clearly stating it in that manner.  Note when when the programmer is not programming (Hi-Z), this LED will tend to pull the target chip towards reset, an undesirable direction & may prevent the chip from running.  You should config so the LED pulls the reset line up.

 

Yes the zeners can give you fits--maybe take them out for now.  The AVR can take 5V anyhow, though signal pins should not exceed vcc (by much).   But yet, here Vcc itself remains unprotected against overvoltage.  What are you hoping to protect against?

Also it is not a good idea to just put a zener directly across an input with no resistance, unless you simply wish to clamp a spike (which might be the case)---usually you'd have a zener with some resistance, otherwise it will try to  "short" your source with brute force. Such brute clamping is good only for a moment (ala a tranzsorb).  The sparkfun design leaves a little to be desired.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sun. Nov 1, 2020 - 06:39 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, I was confused about the reset, but the outcome is the same; the LED is completely irrelevant, because the reset line is at all times controlled by the MCU doing the programming, which can hold it high or low and the LED won't matter.

 

The point isn't the AVR taking or not taking 5V, it's that the USB data lines are supposed to be 0-3.3V. The zeners are load-bearing in the design; if you don't have them, you're going to be trying to shove 5V into the USB cable's 3.3V-rated data pins, which is Definitely Bad. So, that's what they're protecting against; they're protecting the USB signal lines against the 5V signals from the AVR controlling the programming.

 

 

I agree that the sparkfun design leaves something to be desired. I have floating around some signal-conversion boards which can do 3.3V<->5V, but there's a difficulty -- to do that, they need a 3.3V source, and the only power source in the circuit is the 5V, and I don't think I have a suitable voltage regulator lying around. I just thought "sure I can duplicate this circuit, since I know it works, that will be fine", but it turns out to be finicky. Anyway, I think I'll go track down a 3.3V voltage regulator. I considered running the whole thing at 3.3V, but I am under the impression that some of these chips are only rated to about 8MHz at 3.3V, and it needs to be at least 12MHz for the USB driver to work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You should prob call your Vcc +5V instead to make it clear you don't have a 3.3V design.  The only thing shown that looks like a voltage level is 3.3V

if you don't have them, you're going to be trying to shove 5V into the USB cable's 3.3V-rated data pins, which is Definitely Bad. 

Absolutely!  Prob many are 5V tolerant (maybe with their own zeners) or you'd have a low of blown usb stuff from faulty products.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Sun. Nov 1, 2020 - 08:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Further study: Most of the "level shifters" I've been looking at are actually only usable in cases where there's a pullup and the pin is only ever pulled down, but USB appears to require active driving both up and down, so I'd need a fancier device. The alternative would be to run everything at 3.3V, except I don't think the attiny84 can run fast enough on 3.3V. (The data sheet is pretty unclear, it shows a maximum safe speed of 20MHz at 4.5V, and 10MHz at 2.7V, and a sort of line between them. So that's about 10MHz difference over 1.8V of voltage, which implies that 3.3V might be safe for 12MHz, but not for 16MHz.)

 

 

My new plan: I have an AVR Dragon lying around, and found a kit for a ZIF socket thing that supports common AVR chips and an ISP header, and will work from there.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the_real_seebs wrote:

Further study: Most of the "level shifters" I've been looking at are actually only usable in cases where there's a pullup and the pin is only ever pulled down, but USB appears to require active driving both up and down, so I'd need a fancier device. The alternative would be to run everything at 3.3V, except I don't think the attiny84 can run fast enough on 3.3V.

Figure 21-113 clearly shows 3.3V going slightly past the 12MHz line.

At room temperature, you can reliably run them at 12MHz down to 1.8V.  85C might be a problem.  The datasheet doesn't show 12MHz, but it does show 8MHz down to 1.8v in figure 21.114.  If they didn't reliably run at 8MHz down to 1.8V, then how did they produce the graph?

Interestingly, the graph seems to show 85C and -40C down to 1.8V, not just 25C.

 

The Adafruit Trinket t85 is an example of a product that runs at 16MHz with 3V supply.  The comment in the product description saying it should be only run at 8MHz is a misleading claim, since they ship with a v-USB style bootloader that runs at 16MHz.

https://www.adafruit.com/product...

 

 

Attachment(s): 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

... What document are you looking at? My attiny?4 spec sheet is a file called "doc8006.pdf" I got from Atmel's site, well, microchip.com these days, and chapter 21 ends at 21-53. I have a figure 20-2 for maximum safe frequency vs. vcc.

 

In any event, I think I'm gonna give up on this plan -- I found an AVR Dragon lying around, and now I have NEW AND DIFFERENT problems that I don't understand.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the_real_seebs wrote:

... What document are you looking at? My attiny?

Datasheet 8183F–AVR–06/12

 

I have no special talents.  I am only passionately curious. - Albert Einstein

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Huh. Mine is labeled "Rev. 8006K–AVR–10/10", so I think it's a couple of years older. And... ah-hah! There's "complete" and "summary" versions. So I was looking at what's now 21-1 (page 174), which didn't make it nearly as clear. Thanks!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just looked at your schematic.....Theres nothing wrong with it overall.....some people are more picky than others.  I could clearly see what you were doing and your 4 way connections have dots indicating that they are a connection point and that connection point goes to ground.  Again, I see no issue there.  I would connect the crystal directly to the AVR but if you are pressed for space then you do what you need to do...just document it...as you have

 

avrcandies wrote:
Your LED will likely keep you in reset without a strong pullup (that may arm-wrestle the programmer).

With a 2k2 resistor in series to the LED anode?  As long as there are no other series resistors....and I do not see any so theres no problem there.  There is one caveat to this though.... the AVR does have a weak pullup resistor on its RESET line.  The configuration you have currently could keep teh AVR in a state of reset....unless teh TINT pin that controls reset is driven high which will have no issue maintaining the proper level to keep the target out of reset.

 

 

Cheers,

JIm

 

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is very simple....typically when a programmer is not programming, the reset line will do its normal thing.  It's normal thing is certainly not driving an led to gnd, which pulls the reset pin downwards. You want anything connected to the pin to pull it up.  You can tie an led between Vcc and the reset, so it lights during programming (if that is it's purpose), or have a much stronger pullup of some sort to counter the led pulldown.  You want you reset pin solidly near 5V or 3.3v.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Fri. Nov 6, 2020 - 12:20 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the_real_seebs wrote:
Mine is labeled "Rev. 8006K–AVR–10/10",
The nn/mm in Atmel datasheet numbers is a month/date group so your copy is from October 2010 - so pretty old. Ralph's is June 2012.