Replies: 5 comments 4 replies
-
With the lower fuse E2 the clock output is disabled according FuseCalc try 0xA2 instead |
Beta Was this translation helpful? Give feedback.
-
Thank you for this indispensable hint :) I did not know that avrdude's (or the tiny's) fuse bits are inverted from how I understood them. |
Beta Was this translation helpful? Give feedback.
-
Yeah, hans nailed it. As for the other problem, have you verified that you're getting a clock from the active crystal? That's worth verifying. An active crystal absolutely should work. Shouldn't need anything special. That said, active oscillators are a very problematic part to place, because they can be soldered in two orientations. One of them is correct, the other instantly trashes the oscillator when power is connected, because the power is connected backwards. You can typically determine that this has occurred by putting your finger on the active crystal with power connected. oscillators that fail in this way typically get hot after failing (regardless of whether the orientation is corrected - the damage is done). Of course, the bold and legible markings clearly visible on the top of an active crystal will tell you the right orientation... Right. You;re lucky if you can make out a dot on some of those things after cleaning it with alcohol, holding it up to the light just right and looking at it with a magnifying glass. And if you don't know the exact part you're working with, even once you manage to make out the text, it is unusual to be able to determine the part number for any of the SMD crystals smaller than HC/49. When they are marked, frequently it's just the speed. and is not useful for identifying the part unless you have a "lineup" of "suspect" datasheets which you know the part is one of - then you can turn to the markings sections of the datasheets, find the one that matches it and write that part number on the container of them. But it is nearly impossible to perform an identification without any "suspects", particularly if the company isn't known either. I think it's often a combined lot and part code (meaning it's different deppending on when they were made, so when you search for the number online, you won't get any hits, because the lot code portion is different for every lot, and without knowing how the company likes to do lot codes, you're flying blind. prevents the full number from getting search engine hits. Of course, that is all if it has any markings at all. Sometimes the chinese ones are unmarked. In any event, often you can't even find out who made them much less any of the specs other than the headline speed (which is unfortunate, because at least according to digikey, the only western manufacturer selling active crystals that ran from 1.8 to 5.5v stopped doing so sometime in 2020, and all the others available have a much narrower voltage range. It stands to reason that the chinese market is also stocked largely with active crystals with narrow voltage ranges, and there might be a small number making wide voltage range ones. So the active crystals from aliexpress/etc are most likely to have narrow voltage ranges, such that you can't have one oscillator that would work for any voltage an AVR can run at - you just won't know what that voltage range is. So that's a losing proposition; I recommend digikey/mouser for active crystals - the china discount is small, there are more specs to know, and the consequences of not knowing the full specs is more likely to include trashing the oscillator. Passive crystal specs from china via aliexpress are just are bad in terms of information, but at least there the only thing that really matters that you're guessing about is the load capacitance, and that usually varies in a pretty narrow range, and the china discount for 3225 crystals is significantly larger (as a percentage) than for active crystals... But I digress. Oh, and a tiny85, 84, 841, or the smaller flash versions of these can be unbricked with just an HVSP "fuse doctor" (I've seen simple code and wiring diagrams that used a t2313 (or maybe a 4313) as the microcontroller for it. Every other classic AVR (except for some extra-tiny tinies that are too small for Arduino overhead and use a totally different programming protocol) use HVPP - but the 8 and 14-pin parts don't have enough pins for HVPP. Even HVSP takes every pin on the t85, and I think all but 2-3 pins on the 14-pin ones (they make you hold a few extra pins at ground on the 84). HVPP uses 16-18 pins, plus power and ground. All pins except power and ground must be driven actively in HVPP (6 or something are needed for HVSP. The extra pins that need to be grounded on the t84 don't need to be . parts that mark the beginning of it's territory. I think the fuse doctor code itself, since it only had 8 parts, could easily fit a list of the 8 device ID's that it could program, enter HVSP, read the device ID. look up which of the 8 chips it is (we know it will be one of them, because if we read a device ID, we're talking to the chip. and no other chips would understand HVSP). Since fuses are the same across a family, this "database" simply consists of pairing 8 words (the two low bytes of the device sig, the high byte is always 1E) each with one of three three-byte arrays of fuse values - at 25 bytes, it's not exactly big data. The sheer number of connections in HVPP is enough to make it an awful programming method to use. What percentage of the time do you misconnect a given wire? whatever the number, with HVPP you'll have 2-3 times the chance of making at least one wiring error with HVPP than HVSP. while ISP generally uses a 2x3 header, and programming over serial is one 1x6 FTDI-pinout adapter. In both cases the only thing you can do is turn the connector around backwards, and both of those pinouts were carefully designed to be as unlikely to damage the parts as possible if this occurs. so compared to those methods, and assuming near-100% connection accuracy and that your chances of misconnecting any given wire does not depend on whether you have misconnected any other wires the chance of incorrectly wiring HVSP is 6-8 times higher than miswiring single cable serial/ISP for programming, and with HVPP, like 18 times as many (of course this assumption is not correct, but it's not clear which direction this would even bias the results in). A misconnected wire will occupy a pin that another wire probably should be on; so when you get to that wire, you will either misconnect that wire as well (but once one wire is wrong, it "won't work" at all, so this is no worse,) or you'll notice that there's a wire on the pin this wire is supposed to be on, leading you to recheck where the other wire should have been connected, thus correcting the error. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the detail on active crystals. This crystal is certainly one of those anonymous ones with out a datasheet. I hooked up a frequency counter to it's output pin (after frying its twin brother, having applied reverse voltage, and scorched my thumb- which now dons a callus the square shape of a chip on fire). The counter reads 19.999 off of the working chip, so something is right. Thanks to Han's reply I was able to get the tiny85 to output its clock signal that reads around 8.13 on the same freq counter (lower fuse 0xA2). So the test equipment is acting rational. I've also been able to use the clock divider and got 2mhz off the counter. I've also wired up to tinys such that Tiny A's clko drives Tiny B's clki. With the correct lower fuse setting on Tiny B: 0xA0, I am able to read ~8mhz off of both tinys. Hurray. When I take the signal out of the active crystal, and measure it's frequency- I get 19.999. When I then apply this to the CLKI pin of Tiny B (again programmed lower fuse is 0xA0), Tiny B's CLKO pin reads a frequency of 0, and the active crystals output pin's frequency starts wavering between 18 and 19.99 mhz. I can get some logic to work on the board, like blinking an LED but its erratic- delay() calls aren't doing the right thing. I can program the board, but only if the active crystal (or other tiny) is driving TinyB's clock (because of Tiny B's 0xA0 lower fuse). I'm due to get active crystals from mouser, complete with datasheets soon, so I can update this post if I manage to work through this issue. I also desperately need an oscilloscope, and I'm having a hard time finding one that will fit in my small apartment. The pocket ones now available are enticing but they seem a bit slow, and also a bit unproven for this sort of work. In writing all this I just wanted to do a sanity check to make sure i'm not missing any steps. With out a scope I can't tell what waveform this crystal is making, and further, which waveform the tinies expect. Theory was: the crystal is generating a sine wave and tinys are expecting a square wave. Alternative theory: the crystal's waveform is weak and it needs some sort of amplification. Finally the crystal is still on a breadboard- so maybe thats screwing things up (unlikely as the freq counter seems pretty happy with whats being output. Happy to supply wiring diagrams and go into detail- and thanks again for taking the time educate me (both you and Hans!) |
Beta Was this translation helpful? Give feedback.
-
I think I finally got this working- gonna do some more testing, and happy to take advice on how to assure myself that the chip is acting sane. Right now I got a blink program going, and a 20mhz clock coming out of the PB4 pin. Wish there was a way in the IDE to output the clock- is this possible to add? |
Beta Was this translation helpful? Give feedback.
-
The datasheet mentions in Section 6.4:
Clock Output Buffer
The device can output the system clock on the CLKO pin (when not used as XTAL2 pin). To enable the output, the CKOUT Fuse has to be programmed.
Okay so I program the fuse bits as follows:
/avrdude -C~/Documents/Arduino/hardware/ATTinyCore/avr/avrdude.conf -v -pattiny85 -cusbtiny -B8 -e -Uefuse:w:0xFE:m -Uhfuse:w:0b11010111:m -Ulfuse:w:0xe2:m
With the lower fuse set to
0xE2
yielding0b1110 0011
which i think should be read as:CKDIV8: Enabled
CKOUT: Enabled
SUT1: Enabled
SUT0: Disabled
CKSEL3: Disabled
CKSEL2: Disabled
CSKEL1: Enabled
CKSEL0:Enabled
This should yield 8mhz on CKOUT- should I then be able to measure the clock signal on the CLKO pin (pin 4)? Do I need any special code to enable the ouptut?
Beta Was this translation helpful? Give feedback.
All reactions