burning the bootloader with Atmel studio

I decided to take up burning the bootloaders with atmel studio as the only way i ever got it to work from the arduino IDe was with the arduino uno programmed as the ISP which is hideously slow and sometimes i need to do a few.

So i looked up the boards file and identified the fuse settings: 0x05, 0xDE, 0xFF, extended - low, if i use these and read them back after programming the extended fuse is not 0x05 but 0xDF, why is this ? setting the stated fuses in the boards file (and all over tutorials online) does infact flag some yellow exclamations in the programming window which go green after programming and the revised fuse setting has gone in which i seem to have no control over. As far as I'm aware the chips work fine.

I'm assuming that doing the main hex file first or doing the fuses first makes no odds ?

what about the lock bits ? these are rarely mentioned in tutorials but some do.

Alternatively is there a way of speeding up the arduino programmed and an ISP ? but i guess not because the board pretends to be a serial connection to the PC which is max 115 Kbps.

You can try Nick Gammon's programmer.
I stopped using Atmel Studio because it took sooooooo loooooooong to open up.
Does burn the bootloader nice & quick.

You can review
28. Memory Programming
and see what the individual bits do.
Unused (not programmable) bits tend to read back as 1, hence the result being different.

When I did use Studio, I made the lock bits unlocked, set the fuses, and then did the bootloader.

Programming is over SPI using Atmel MKii programmer, and goes quick when only the bootload space is programmed.

New chips, you have to program at a slower speed the first time.

CrossRoads:
You can review
28. Memory Programming
and see what the individual bits do.
Unused (not programmable) bits tend to read back as 1, hence the result being different.

ok That means nothing to me. Where can I find the programmer ? is it a standalone software or an arduino sketch. I gave up getting the AVRISP2 to work with the arduino driver, got it to work on my main Pc and now that won't use it when I reinstall the original driver for AS, I can't get it to work on other computers so I give up. AVRISP2 + Arduino IDE = waste of time in my experience and not a reliable solution.

Good luck.

AVRISP2 + Arduino IDE = waste of time in my experience and not a reliable solution.

And yet that is what I use exclusively, here loading an Atmega1284P based Duemilanove style board (FTDI interface vs Uno style USB/Serial interface.


Atmel Studio installs Jungo driver for the MKii, I had to un-install that and install the MKii driver that is included in one of the IDE folders.
There is a way that both can be supported, it was described here in the forum, maybe by member hiduino? I didn't go that route as AS was taking too long to start up; I live with the slightly slower bootloading vs waiting (ages it seems like) for AS to start up to bootload a bit quicker.

well like I said I was more miss than hit for me and I need something that will work on all my computers. Unfortunately other than follow the instructions to disable the requirement for a signed driver and to install the arduino driver instead of the jungo one, if it refuses to work there is nothing I can do.

after programming the extended fuse is not 0x05 but 0xDF, why is this ?

Only the low three bits of efuse are implemented, and there is some ambiguity whether an unimplemented bit should show up as "0" like a programmer would expect, or as "1" as it would if it were an "unprogrammed fuse" (remembering that "1" is the unprogrammed state for fuses, and a "0" enables whatever fuse function is controlled by that bit.)

I'm assuming that doing the main hex file first or doing the fuses first makes no odds ?

Probably not, as long as you're programming the fuses correctly. Note that you should only have to program the fuses once.

what about the lock bits ? these are rarely mentioned in tutorials but some do.

they're in boards.txt as well, as "unlock_bits" and "lock_bits."
The overall procedure done by the IDE for something like "burn bootloader" is:
set the lock bits to the "unlock_bits" value.
program the fuses and the .hex file, all in one avrdude commmand.
set the lock bits to the "lock_bits" value.

so if the extended fuse is going to be 0xDF in the end why not just set it to this in the first place. I am aware that in the AVR individual bits cannot be accessed, is this the sort of case ?