Here is the fuses_mike.txt file from the bootloader folder:

EFUSE = 0x00
0   -
0   -
0   -
0   -
0   -
0   BOOTSZ1 (1024 word boot size)
0   BOOTSZ0     ""
0   BOOTRST (jump to bootloader)

HFUSE = 0xd5
1   RSTDISBL
1   DWEN
0   SPIEN
1   WDTON
0   EESAVE
1   BODLEVEL2   (sets V_BOT=2.7)
0   BODLEVEL1       ""
1   BODLEVEL0       ""

LFUSE = 0xf7
1   CKDIV8
1   CKOUT
1   SUT1    (65ms start-up delay)
1   SUT0        ""
0   CKSEL3  (full swing crystal oscillator)
1   CKSEL2      ""
1   CKSEL1      ""
1   CKSEL0      ""

LOCK = 0x2f
0   -
0   -
1   BLB12   (can't self-program over bootloader)
0   BLB11       ""
1   BLB02   (no restrictions on programming application code area)
1   BLB01       ""
1   LB2 (no memory lock)
1   LB1     ""

And here is the Fuse settings on a non functioning ATmega168 viewed with AVRStudio 4:

The mcu just shows the two black bars on the lcd regardless of the programing switch position. I thought I'd look at the fuses and all I see is confusion. Can anybody reconcile mikes documents with what I am seeing. Are the fuse settings the reason why the device is not working?

I will not even speculate about what happened to the device I have not touched it for a month or more it has been just sitting in a box not hooked up to anything. I actually have two ATmega168s that are not working correctly. Both had been working a month ago.

So where do I start? I have a STK600 programmer so I can erase the chip and supposedly set the fuses. I do not see any correlation between mikes document and the fuse setting options. There is no EFUSE, HFUSE, LFUSE or LOCK.

I really cannot not make any sense about any of this, of course I know absolutely nothing about the fuses and their settings.

Thanks for the help,

Ralph

I doesn't look as though your hardware and software are talking... It says entering programming mode.. FAILED! at the bottom.

Anyway, if it is talking, your fuses are messed up.

Around the center of the screen it's showing the fuse byte values all as 0xFF.

EFUSE = Extended Fuse byte

HFUSE = High Fuse byte

LFUSE = Low Fuse byte

Your lock bits would show on the LockBits tab.

I've never used avr studio for much of anything so I can't really help you on that side of things.

Rick

Thanks Rick, I almost had gotten to the point of understanding HFUSE = HIGH, duh it's amazing how my mind is not working.

The SPIEN with the question mark means there is problems with communications.

It is really interesting I have two ATmega168s that are exhibiting the same behavior, two black bars no matter the switch position but one of them is at least connecting though I can not program it with the boot loader.

Now why would two chips that were working stop? It has to be something I did in my learning programming exercises. I know one of the chips I loaded the bootloader on with a beta ISP programmer (other 328p chips I loaded the bootloader on with the ISP programer work fine).

I have a 328p chip that I screwed up trying to put a switch on the reset pin, that was why I wanted to get the ISP programmer to see if I could recover it.

I guess I will have to learn High Voltage programming, of course that means I'll have to restore one of my older windows computers to get a parallel or true serial connection, good thing I have lots of time on my hands.

Ralph

I don't have any high voltage programming equipment.. always thought of getting an STK500 for that but never have. High voltage is the only way to fix a chip where the fuse settings have rendered it inoperable. I'm really surprised you can't at least read the chip. I know if the fuse bit that disables the reset pin is set pin 1 will no longer reset the chip when grounded and then ISP programmers will no longer work. However, if you weren't playing with setting fuses I don't know how that would have been set. A static zap could have killed them completely but as careless as I am, I've yet to zap one myself...

Rick

I know the 328p went south when I tried to set a reset switch using your thread on reset switch. I used a regular spst switch not a momentary contact one. The chip died after the first attempt, I really do not remember exactly what I did of course I hold you harmless :-).

But these two 168p mcus were just sitting in a box, I see from last August I was having trouble and asked about the two black bars persisting no matter the switch position. It appears at that time I got the programming working by switching back to the 168 libnerdkits folder (I had been using the 328 libnerdkits version). I had thought using the 328 libnerkits had been working with the 168 but maybe it just set this up to happen. Well I'll keep playing, the STK600 will do high voltage programming so eventually I'll get around to learning how to do that.

Ralph