Trouble reviving an AtMega 168 with STK500 Clone

Forum 2005-2010 (read only) Hardware Troubleshooting
1

Hey guys,

I've got a Romeo board which was working great until I loaded a sketch which was to big for memory. Ever since then it doesn't respond to USB programming (though the FTDI is recognised).

I picked up an STK500 clone programmer and used AVR Studio to burn one of the bootloaders - that seemed to work fine (though it's the first time I've ever done that) but the board still isn't responding to USB.

Is there a way, in windows, to upload a sketch via the ISP programmer? If I can get a blink sketch running then at least I know it's still working and it could be the FTDI connection.

Does anyone have any ideas?

Cheers,
Miles

2

if you clear out your applet folder and then attempt an upload in the arduino ide, it will build a hex file that you can write with an isp programmer and avrdude

what errors were you getting with the isp programmer you have?

3

Via usb I get STK500 timeout.

STK500 ISP programmer works fine.

So if I compile blink as you suggested I can burn that into the flash - does that include the bootloader to upload it?

FYI:

4

also, I had an issue with what avrdude said was correct with the efuse vs what i had to write. check that out here

basically the efuse has to be 0 instead of the f8 that it wants to write

5

Hmm, per your guide I droped back from F8 to 0 and I got:

Writing fuses address 0 to 2.. 0xFF, 0xDF, 0x00 .. OK!
Reading fuses address 0 to 2.. 0xFF, 0xDF, 0xF8 .. OK!

WARNING: Fuse bits verification.. FAILED
Leaving programming mode.. OK!

6

i know that the f8 to 0 is for avrdude which was where i was writing it. im not sure / have not used avr studio. if it writes the bootloader correctly with f8 instead of the 0, then you should probably use that when writing the blink hex

7

That seemed to work great. I've tried to upload a sketch and, alas, it still doesn't work

"
Could not delete H:\arduino-0017\examples\Digital\Blink\applet

Binary sketch size: 896 bytes (of a 14336 byte maximum)

avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x51
"

8

Adding some more mystery to this problem. I've uploaded the "Serial Communications" sketch to rule out a FUBAR FTDI connection. Nope, it works great. Communication is two-way - very strange.

Could the lack of auto-reset cause the STK500 (within the 168 bootloader) to void an upload?

9

Hey guys,

With some trial-and-error I managed to finally figure out what was up. I'm pretty sure the problem started with a sketch which used up all the RAM on the device which led it do commit suicide.

The reason why the Romeo did not take to the bootloaders I loaded was down to corrupt fuses. Though you could load sketches and/or bootloaders it still wasn't responding. I believe this was a clock issue!

With another Arduino on hand, specifically a Seeeduino clone (168) I decided to verify my hypothesis by nuking it. It did exactly what I expected. I reverted it back to it's original settings and moved onto the Romeo.

I accidentally managed to slow the clock down yet further. Using AVR Studio I set the read clock speed to 140~ Hz and went about setting the fuses (etc) to the following:

I then burnt the seeeduino bootloader, to be consistant, to the Romeo. It all came alive!

We're back in business :wink: Hopefully this will help someone