What's the chance that these are firmware limited in later builds? Just trying to explain how some people are changing crystals but not getting overclock. Are they changing the wrong crystal?
My 16MHz oscs are on the way, hope to mod this week.
I continue to suspect the firmware. I modded a device to 16MHz today, and got the same behavior as other failed overclockers. I'll describe it as follows: Startup fine, recognition fine. Then green LED goes out for a bit as cgminer takes over, and gives fast blinks on first few accepts. But as soon as the reported hash rate starts ramping up, it trainwrecks: you get a long-ish blink and hash rate starts over from 0. It really looks like if the hash is returned quicker than the micro expects, it flushes everything (I'm assuming it's pipelined, to get one hash per clock) and starts over. Valid accepts are certainly generated when it's running, just the device keeps resetting after a bit. Hash rate definitely exceeded 335, but I'd say I never saw higher than about 380Mhz peak with a 16.000M osc before it resets.
I tried several feedback resistors (1.2k, 1.33k, 1.4k) and the action was the same except for increased supply current. Scope tells me the clock is good, the core supply is good and chip is definitely not in overcurrent (better inductor + external 5V). Heat was not an issue: With a big slab heatsink, chip temp was lower than running stock, and way lower than running stock with no forced air. So this sounds like one of a couple of things.
1) It's an honest bug, due to a slowly clocked micro (clock limited to 12MHz using 3.3v supply, check the d/s). Starts reading too late, gets the wrong answer and bails out. Or gets totally munged and a watchdog eventually kicks it. If there is no interrupt or anything, and it's really pipelining up to 1 clock per hash, it could be a very delicate balancing act to push and pull data quick enough to feed the asic without trainwrecking. Anyone who knows a little more nuts and bolts about this chip, please chime in.
2) It's a new "feature" to best monetize dollars per hash rate. My devices are not the first build, so maybe firmware was updated in response to all the overclocking interest. It would probably be quite easy: Check a timer, and if the asic is giving results too fast - user must be cheating. Not that this is bad, or dishonest - it's asicminer's device, and you're paying your $50 for 335MH/s. No more, no less. But for us, it represents a limitation in the hardware we bought, and we have the desire to try to improve it.
I have not slurped the serial comms with a logic analyzer, but that's the next logical step in trying to figure out what's causing the resets. Or fetching the firmware, but chances are it's locked.