Great thread. Glad you successfully sorted that out thanks to nitro2k01. There's nothing like building your own stuff.

ooooooookay so apparently the other 8515 is totally fine! Who knew? Well, nitro did, that's who!

wowwwww, okay! that makes sense but it would have taken me a DAMN long time to figure that out. Thanks again!

As for the other 8515, I'm gonna try it out some more and see if it will take programming again, but I'm pretty sure it's fried.

Alright. It's all about reading the manuals and noticing little things. Those fuse bits are what's actually recommended by the build manual. But that's not what made me change it. The crucial setting is what the fue calculator describes as "Ext. Clock/RC Osc./Low-freq. Crystal: enable internal Capacitors (36 pF) Internal R/C Osc.: leave unchecked! External Crystal: enable full swing (neccessary for >8 MHz)" The important part is "enable full swing" which makes the oscillator circuit go between 0 V and 5 V instead of running on a lower voltage, presumably to save power. This reminded me of something from the FT232BM datasheet.

So without that fuse bit set, the clock line will not reach the switching threshold and the FTDI chip will not be properly clocked, and USB will not work.

So, now I want to know, is one of the Atmega chips actually broken?

That did it! Thank you! This pile of junk is now a functioning cart flasher! Now you've got to tell me what the new fuse values mean and why you changed them...

What do you mean by bunk? "Broken" or "bogus"? Is one of the ATMega chips still broken, ie can't be programmed even with the added crystal?

Did you check the value of the capacitors? I have new fuse values which I think may solve the problem: Low: 2E, High: C9. Would hate to have you send the flasher all over the world if the solution is something simple like that.

yep, that confirms that the fuses are set correctly - so at this stage am I safe in assuming the ftdi chip is indeed bunk? I mean the atmega was bunk, so maybe whatever happened to one happened to the other? I believe this brings us back to the "mailing it to Sweden" stage.

Probably an avrdude quirk. Try reading the fuses individually with the following switches, rather than just looking at the summary.

-U lfuse:r:-:h -U hfuse:r:-:h -U efuse:r:-:h

The plot thickens - I checked it in atmelstudio and it lists them correctly - H 0xD9 and L 0xEE, no efuse listed at all. So is that just a quirk of avrdude?

alright! That did it, thanks. So I got the new chip programmed, it's doing great and all. Then I get the same symptoms... no device recognition on XP or OSX 10.6.8 (FTDI drivers installed of course).

So I pop the atmega back in the programmer and check everything - apparently when I set the high fuse, avrdude is actually putting that value in the efuse slot - I'm getting

"Fuses OK (H:FF, E:D9, L:EE)"

the hell?

edit: to be more clear, if I set an lfuse value, it goes to L. If I attempt to set an hfuse value, it goes to E. If I attempt to set an efuse value, it says there's no such thing!

Huh, alright I'll take another stab at this tomorrow. Luckily I have extra crystals...

Haha..I did this a few times with my versions. Programming the atmega fuses before setting up my ftdi clock output. It scares you if nothing else...

This is normal. Burning the EE fuse value tells the chip to disable the internal RC oscillator and use an external crystal. The chip needs a clock signal to be programmed, so the chip won't work while in the AVR programmer, since it has no crystal or other clock source. I should have thought of this before recommending that fuse value, given that I saw your AVR programmer. (If you had programmed the flash memory and high fuse first, the chip would be usable now.)

The quick'n'dirty way to solve this would be to add a crystal between the same two pins as in the actual circuit. The value shouldn't be too critical for just programming the chip. Any crystal >=1 MHz that doesn't exceed the rating for the chip should work well enough for the purpose.

You MAY be able to program the chip adding the -B 1.0 switch to avrdude, but if it works it will be slow as a dog's butt.

The less quick'n'dirty way of solving this is to add some form of programming header to the board, so the AVR chip can be programmed in circuit. If you had sent it to me, I probably would have done this just for my own convenience.

However, with this in mind you should be able to plug the chip back in to the GB programmer and notice an improvement. There's no code on the chip, so it won't work as a flasher, but now that the crystal should be oscillating at 6 MHz, the FTDI chip should be identified since it should be able to communicate over USB.

Well to be fair, this is the only project I've used it for - so the data isn't statistically relevant but perhaps that's not the best track record.

How sure are you of your programmer?