I'm putting together a custom board with a '168 on it, and trying to upload Lilypad's bootloader to it with AVRstudio4 and AVRisp II. The code seems to upload fine. I have the "boot" led on pin 17 to check the bootloader.
I have found the fuse settings in the Arduino hardware directory
Some of the extended fuse bits aren't used. The program used by Arduino to set the fuses, avrdude, uses a 0 for these unused bits while AVR Studio uses a 1. The fact that you get F8 shouldn't be a problem (although you might want to use that as the value you set the extended fuse byte to).
Apparently Arduino 17 needs exclusive use of the AVRISP II USB drivers, so I'd have to switch drivers over to use it and AVR studio, so I'll stick to the power of the studio functions. What I need is a clear statement of the fuse settings !
....and today I have changed them VERY slightly to enable clock out, and have a prod/measure with the scope and frequency meter. The clock is pretty well perfectly 8 Meg - certainly to within better than 1%.
My actual fuses as read back are
Extended 0xF8
Low 0xA2
High 0xDD
And my lockbits are now 0xCF.
There is an LED on sck as per the Lilypad schematic, but no joy at all -there is no activity on that pin, except when the AVRISP is clocking the chip.
The damned thing isn't booting the bootloader, and I don't know where to go next with it.
looking at the fuses in the datasheet I note that the only differences between your actuals and the lilypad's list are the clock-out one which you've deliberately changed and the 5 high bits of the extended fuse which are not used and, per mellis above, are treated differently.
the lock bits are different but again those look like unused high bits. As I read it, only the boot section is locked which is presumably what you want and if avrisp burns and verifies it they must be unlocked during its download (you'll note that the ..xx .... lock bits which control the boot section are what change between the two lilypad sets).
All I can suggest is, since you're comfortable with AVR studio, write a little routine and flash it or jump onto avr freaks and look around there for another bootloader and fuse setup.
Good plan Bill. Thanks. I DID try the AdaBoot version of the bootloader, but no dice there either.
I'd better try a fresh chip - this little project has a TQFP version, so I'll hack something in a DIL pack when I get a few chips on Tuesday, just for a sanity check that its NOT the CPU.
dumb question: the bootloader goes in high flash which could otherwise be used for your own code. what makes the avr start at cf00 when there's a bootloader and 0000 if there isn't?
so the reason I've been following this thread is that I want to run a 168 without a crystal. I have my app ported to a 168 running 8mhz internal and it's fine including 115200 serial. I compiled my app for lilypad but burned it with avr studio because no bootloader yet. I'd like the bootloader so i'm going to try that later this evening.
I note, in passing that my fuses are now E2 DF F9 and lockbits FF. I'll look into the boot reset vector fuse when I get to that.
with much trepidation I reset fuses and uploaded hex files and I now have the lilypad bootloader successfully installed and talking to the ide.
my fuses are set at E2 DF F8, lockbits are CF. When I wrote the boot loader I had the lockbits at the default of FF. The CF just protects the bootloader section now. The other significant change was the extended fuse byte to F8, the bottom bit is what actually causes the boot loader to run.
so default fuses 62 DF F9 lockbits FF
changed fuses to E2 DF F8 to run 8mhz with 2k bootloader active
left lockbits at FF,
flashed LilyPadBOOT_168.hex
changed lockbits to CF
I could tell right away that the bootloader was in because pin 19 blipped every 10 sec or so.
An afternoon of hacking and prodding with an oscilloscope and I am no further on
The program from Arduino17
C:\Program Files\arduino\arduino-0017\hardware\bootloaders\lilypad
lilypadboot_168.hex
....and today I have changed them VERY slightly to enable clock out, and have a prod/measure with the scope and frequency meter. The clock is pretty well perfectly 8 Meg - certainly to within better than 1%.
My actual fuses as read back are
Extended 0xF8
Low 0xA2
High 0xDD
And my lockbits are now 0xCF.
There is an LED on sck as per the Lilypad schematic, but no joy at all -there is no activity on that pin, except when the AVRISP is clocking the chip.
All I can see in your notes is that you don't say you unlocked the lock bits before writing it but since it verified, either you did or it doesn't matter.
All I can suggest is a fresh start. if blinky can run the bootloader should pulse pin 19.
Yes, I didn't explicitly unlock anything, since I was erasing the device completely over the SPI, and I got no error messages. However, I'll have to try your settings and see what happens.
Thanks for a new angle of attack !
.....now I've tried it. Still no joy. Did exactly what you said. Same fuses. MAde sure protection fuses weren't set, programmed, flipped the protection fuse to CF.
huh. What about your hardware setup. I know blinky runs but what about something that uses serial? I ran my first proof of concept on a solderless breadboard with only the dragon's programming leads attached. I was able to see the bootloader pulsing pin 19 but I didn't try to run it til I had it on a pc board with bypass caps etc.
a little further learning: the lilypad bootloader has a heck of a long delay before the app gets to run -maybe as much as 10 sec. My 168 seems to run about 2% fast on the oscillator. Neither of these is germane to your problem.
I can't see screenshots doing you any good but anything else I can do I'm happy to try.
Now this thing is powered over an FTDI USB/serial cable. Does the bootloader look for active serial comms and lock out ? Can't test that theory without surgery to the board.....
