Offline
Sweeeeeeden
Jazzmarazz wrote:
nitro2k01 wrote:

For this version it's more like L: 0xEE and H: 0xD9. Especially for the low fuse.

Even though he is using an external crystal? I will not argue with you of all people, but this was my understanding.

Yes. External clock source is different from using an external crystal. External clock source means you're generating the clock somewhere else on the board and send it to the clock input of the Atmega. (Such as in your (jazz's) flasher and mine, where the clock is generated in the FTDI chip.) If you're using an external crystal connected between the X terminals, choose external crystal in the drop down and the appropriate frequency range.

Offline
Matthew Joseph Payne

huh!

okay I'm going to try to make it down to work to grab my AVR programmer and hopefully later today I'll get a chance to try these solutions (cleaning and inspecting traces, setting fuses). Thanks guys!

Offline
Michigan

My concern is that there should have been a drivers installation of your FTDI chip. you mentioned nothing popping up at all and in my case, I at least got a "malfunctioning USB device."

Clean those traces and get back with us. smile

Offline
Matthew Joseph Payne

I just cleaned up as much of the flux and corrosion as I could, then retested every leg of the FTDI chip that actually goes somewhere. And yes, the lettering is perfectly readable now, hah.

Now I'm reinstalling the AVR programmer's drivers and junk so I can try to set the fuse bits...

Offline
Matthew Joseph Payne

I think I finally determined that my 8515 was dead. Who knows how that happened, it's been in storage for awhile.

So I swapped it out for another one. When I wrote the low fuse as EE, it worked - then it also died (errors on all attempts to program). I'm reading here that programming the fuses incorrectly can kill these things?

Offline
Michigan

How sure are you of your programmer?

Offline
Matthew Joseph Payne

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.

Offline
Sweeeeeeden

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.

Last edited by nitro2k01 (Dec 19, 2013 12:41 am)

Offline
Michigan

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...

Offline
Matthew Joseph Payne

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

Offline
Matthew Joseph Payne

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!

Last edited by kineticturtle (Dec 19, 2013 5:58 pm)

Offline
Matthew Joseph Payne

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?

Offline
Sweeeeeeden

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
Offline
Matthew Joseph Payne

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. smile

Offline
Sweeeeeeden

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.

Offline
Matthew Joseph Payne

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...