Hi, I'm working with an ATmega32u4 but having problems setting the fuses so the eeprom isn't erased during an upload.
I'm programming the chip using the Tiny AVR Programmer and the Arduino IDE v1.6.5.
I started by using the IDE to burn the Leonardo bootloader, this works well however the eeprom gets erased when I upload. I searched for fuse addresses but couldn't find anything so I used one of the fuse calculators and checked the EESAVE box and came up with the following which I uploading using avrdude.
After that the eeprom was ok however the I2C bus quite working. I upload the Leonardo bootloader again and I2C works but not eeprom.
Then I got brave and started making changes to the fuse settings and finally bricked my chip lol. I think I disabled the reset pin or programming pins. Now I'm scared to make more changes so hoping someone might have the answer.
Here are the fuse settings that resulted from that command:
The most significant other change you made is programming CKDIV8. I suspect that's the explanation for your I2C problems.
If you want to have success with electronics and programming, it's very important to train yourself to take a methodical approach. Only change one variable at a time. In this case, change only the EESAVE bit, then test to see the result of that change. Only after doing that should you proceed to change another variable, if desired.
As for unbricking, I don't have experience with that subject since I've miraculously managed to never brick a chip in my years of shenanigans with playing around with fuses. Hopefully someone else here can provide advice on that.
Thanks pert, I will try that tonight. The reason more changes were made than just EESAVE is because I couldn't find a set of default fuses like you kindly posted, maybe I didn't search hard enough, so using the calculator I set the options I thought were correct and added the EESAVE bit, I was lucky my changes didn't harm it.
This is how I bricked it, using the same calculator you posted, notice the "default" line in grey after bit 0 with an address on a button. I thought maybe those were all the default settings for ATmega32u4 but yeah far from it lol. That's what bricked it. I'm usually pretty careful and don't damage too many things but I must admit I got a little careless. I bookmarked that default list of fuses so I have a base to start from.
Based on my search it is possible to unbrick the one I have but I need to use a high voltage (12v) programmer however this requires removing the ATmega32u4 from it's circuit as it uses 12v. Sounds like I messed up SPI so I can no longer program with this method, chip is technically ok though. Definitely not worth the trouble for a $5 part so I will take the loss.
I should be set now though, thanks for your help, I appreciate it!
There are 2 or more sets of default values for fuses on the ATmega32u4. Pert gave you the link above labeled "fuse settings for Leonardo" that took you to the boards.txt file that is part of the Arduino IDE software. That same boards.txt file is on your computer, buried in a subdirectory of your IDE installation. Those are the fuse values that the designer of the Leonardo board decided to use. The other set of default values are the values that the chip comes loaded with when it ships from the factory. Those values can be found in the data sheet for the ATmega32u4, which is a good document to read. It is available for download on the microchip.com website.
A high voltage programmer only applies a 12V signal on the reset pin, and otherwise runs at 5V, and you can make one using an Arduino, a transistor, and some resistors. So, it's not a huge deal, but it does require a lot of wire connections so it is kind of a pain. It's not worth doing for a $5 part, but it is good knowledge to have anyway because it lets you experiment with all the possible fuse values, including disabling SPI programming, and then you can simply recover from that. https://www.instructables.com/id/HV-Rescue-Simple/
Thanks dmjlambert, good to know about other fuse settings. I did recognize the defaults posted by Pert was from the IDE, I did look around in the directories but only found the hex file which I couldn't obviously read. Didn't think of checking the datasheet though, I should have. After replacing the chip I did an upload before setting any fuses to see how it works, with the features I'm using it was the same as Leonardo fuses, eeprom still didn't retain. I was a little surprised the Leonardo bootloader didn't have eeprom retain enabled.
For the high voltage programmer I came across the DIY version with Arduino but yeah what a mess, take me hours to setup. I agree though having one is good to experiment but as it typically goes, no time right now.
Back to the chip erase thing. Here are my findings:
When I upload a sketch using a programmer, and the high fuse is set to D8 (default for Leonardo), EEPROM is erased
When I upload a sketch using a programmer, and the high fuse is set to D0 (EESAVE bit added) , EEPROM is not erased
When I upload a sketch via the Leonardo bootloader and USB, and the high fuse is set to either D8 or D0, EEPROM is not erased.
The programmer I'm using is an Uno with the Arduino as ISP sketch installed.
That solved my mini mystery as to why the Leonardo bootloader doesn't have the EESAVE bit added as the end user programs it by USB. I'm using the Tiny AVR programmer so have IDE set to USBtinyISP which gives me the same results as your programmer setup. Technically I don't need the EESAVE as this will only be programmed once but right now during development having the eeprom retain is nice.
In addition to being what an Arduino board comes with when you buy it, the fuses defined in boards.txt are set when you do a Tools > Burn Bootloader in the Arduino IDE. So another way to get the Arduino fuse values is to enable File > Preferences > Show verbose output during: upload, do a Burn Bootloader, and then find the command that set the fuses in the black console window at the bottom of the Arduino IDE window. Burn Bootloader is a two step process. The first step sets the fuses and the second step flashes the bootloader .hex file. So you need to scroll up until you find the first command.
I agree though having one is good to experiment but as it typically goes, no time right now.