Edit: What exact avrdude cmd line did you use? I don't see the fuse values after the signature, which I would have expected.
-c usbasp -p m48 -P USB -B 8 -v -v -v -v
Edit: What exact avrdude cmd line did you use? I don't see the fuse values after the signature, which I would have expected.
-c usbasp -p m48 -P USB -B 8 -v -v -v -v
naut:
phew.... I think it's working now.
Both chips?
naut:
I was able to upload the blink sketch to the Atmega48 in the ZIF socket. The slow clock jumper works, and I changed the boards.txt definition of Atmega48 to:atmega48.name=---ATmega48---
atmega48.upload.protocol=avrisp
atmega48.upload.maximum_size=4094
atmega48.upload.speed=9600
atmega48.upload.using=USBaspatmega48.bootloader.low_fuses=0xe2
atmega48.bootloader.high_fuses=0xdf
atmega48.bootloader.extended_fuses=0xff
atmega48.bootloader.path=atmega
atmega48.bootloader.file=ATmega48.hex
atmega48.bootloader.unlock_bits=0x3F
atmega48.bootloader.lock_bits=0x0Fatmega48.build.mcu=atmega48
atmega48.build.f_cpu=1000000L
atmega48.build.core=arduino
atmega48.build.variant=standardso I just changed the baud rate to 9600 and clock speed to 1 MHz. btw, also works with 38400 Baud rate.
Now I want to try to burn the fuses so it would use the external 16Mhz crystal.
Where did you get your fuse settings from? You didn't just copy them from another chip? That definitely won't work.
I'm still puzzled why you didn't get the current fuse values read back.
pico:
Where did you get your fuse settings from? You didn't just copy them from another chip? That definitely won't work.
OK, those fuse settings look like the only thing they change from factory is to lose the DIV8 for the clock, so you'll be internally clocked at 8MHz rather than 1MHz. Which is probably a good place to start with the programming because you don't need to worry about the external xtal at this stage. So change
atmega48.build.f_cpu=1000000L
to
atmega48.build.f_cpu=8000000L
in the board.txt decription.
pico:
I'm still puzzled why you didn't get the current fuse values read back.
Still puzzled. You can use avrdude in interactive mode (-t) to query and rewrite the fuse settings if need be. More direct control than going through the IDE, until you are confident everything is correct.
Both chips?
yep, uploaded the blink sketch to both of them.
Where did you get your fuse settings from? You didn't just copy them from another chip? That definitely won't work.
If you mean the bootloader fuses, I don't know, I don't remember where I found this Atmega48 definition.
Since I don't need a bootloader I removed the
atmega48.bootloader.low_fuses=0xe2
atmega48.bootloader.high_fuses=0xdf
atmega48.bootloader.extended_fuses=0xff
atmega48.bootloader.path=atmega
atmega48.bootloader.file=ATmega48.hex
atmega48.bootloader.unlock_bits=0x3F
atmega48.bootloader.lock_bits=0x0F
part from the definition so now I only have:
atmega48.name=---ATmega48---
atmega48.upload.protocol=avrisp
atmega48.upload.maximum_size=4094
atmega48.upload.speed=38400
atmega48.upload.using=USBasp
atmega48.build.mcu=atmega48
atmega48.build.f_cpu=1000000L
atmega48.build.core=arduino
atmega48.build.variant=standard
The blink sketch still uploads fine.
I'm still puzzled why you didn't get the current fuse values read back.
I'm using a AvrDudesGUI, I think it saves the fuses info to some temp file that I was not able to find.
What is the command for getting the fuse info in command line avrdude?
naut:
I'm still puzzled why you didn't get the current fuse values read back.
I'm using a AvrDudesGUI, I think it saves the fuses info to some temp file that I was not able to find.
What is the command for getting the fuse info in command line avrdude?
The cmd for getting the fuse info is the one you are using. I didn't realize you were going through a GUI. Best to work from the cmd line, at least initially -- eliminates possible complications arising from the extra layer. avrddude is a very direct tool to use in the command line.
Try the
avrdude -c usbasp -p m48 -P usb -B 8 -v -v -v -v
cmd you used again, but this time directly from the command line, and see if you get fuse readings this way.
(When setting fuses, best to proceed slowly and carefully when working on a new chip.)
To go into terminal mode (interactive mode), try this:
avrdude -c usbasp -p m48 -P usb -B 8 -t
you'll get a cmd prompt from within avrdude
enter
r lfuse
followed by
r hfuse
and finally
r efuse
that should read your fuse values if all else fails.
you can quit by entering
q
and you adjust your fuses by
w lfuse 0 0xe2
for example.
Try the
avrdude -c usbasp -p m48 -P usb -B 8 -v -v -v -v
cmd you used again, but this time directly from the command line, and see if you get fuse readings this way.
here it is:
avrdude: Device signature = 0x1e9205
avrdude: safemode read 1, lfuse value: 62
avrdude: safemode read 2, lfuse value: 62
avrdude: safemode read 3, lfuse value: 62
avrdude: safemode: lfuse reads as 62
avrdude: safemode read 1, hfuse value: df
avrdude: safemode read 2, hfuse value: df
avrdude: safemode read 3, hfuse value: df
avrdude: safemode: hfuse reads as DF
avrdude: safemode read 1, efuse value: 1
avrdude: safemode read 2, efuse value: 1
avrdude: safemode read 3, efuse value: 1
avrdude: safemode: efuse reads as 1
avrdude: safemode read 1, lfuse value: 62
avrdude: safemode read 2, lfuse value: 62
avrdude: safemode read 3, lfuse value: 62
avrdude: safemode: lfuse reads as 62
avrdude: safemode read 1, hfuse value: df
avrdude: safemode read 2, hfuse value: df
avrdude: safemode read 3, hfuse value: df
avrdude: safemode: hfuse reads as DF
avrdude: safemode read 1, efuse value: 1
avrdude: safemode read 2, efuse value: 1
avrdude: safemode read 3, efuse value: 1
avrdude: safemode: efuse reads as 1
avrdude: safemode: Fuses OK
So the USBASP reads the fuses twice? Just to be sure?
What do these values tell us?
(When setting fuses, best to proceed slowly and carefully when working on a new chip.)
I'll use AVR® Fuse Calculator – The Engbedded Blog to calculate the fuses.
naut:
So the USBASP reads the fuses twice? Just to be sure?
Three times, actually.
naut:
What do these values tell us?
OK. efuse is 0x01, which is fine, because only bit 0 is used, bits 1-7 are "don't care" values.
lfuse is 0x62, which is still factory, with the DIV8 bit set, so you are still clocked at 1MHz
hfuse is 0xdf, which is also still factory.
So your chips are still at their factory settings.
The first thing I would do is to unprogram the DIV8 bit (set it to 1), and get them internally clocked at 8MHz.
This means the value you want to set the lfuse to is 0xd2.
You could do this from the cmd line like so:
avrdude -v -v -v -v -pm48 -cusbasp -Pusb -Ulfuse:w:0xd2:m
(notice the order of the avrdude cmd line options don't matter.)
Once you've done that, you should find you no longer need the slow clock setting on the USBasp to communicate with them.
Also, you could use that boards.txt entry you found unaltered, as the fuse settings would now be in agreement with that.
Just make sure to change back the
atmega48.build.f_cpu=8000000L
like (I assume) it was originally.
I would think then you were good to go for programming these within the IDE using the USBasp (no bootloader, obviously.)
After you've got that all verified as working correctly, we can get you set up with an alternative modified entry to use with a external 16MHz xtal. Have to change the lfuse again, and have to change
atmega48.build.f_cpu=8000000L
to
atmega48.build.f_cpu=16000000L
but one step at a time! Get the internal 8MHz clock set-up working first.
I've got to go for now -- talk to you later.
hey thanks, you're being very helpful!
so here is the avrdude output:
vrdude.exe: auto set sck period (because given equals null)
avrdude.exe: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.03s
avrdude.exe: Device signature = 0x1e9205
avrdude.exe: reading input file "0xd2"
avrdude.exe: writing lfuse (1 bytes):
Writing | ################################################## | 100% 0.02s
avrdude.exe: 1 bytes of lfuse written
avrdude.exe: verifying lfuse memory against 0xd2:
avrdude.exe: load data lfuse data from input file 0xd2:
avrdude.exe: input file 0xd2 contains 1 bytes
avrdude.exe: reading on-chip lfuse data:
Reading | ################################################## | 100% 0.01s
avrdude.exe: verifying ...
avrdude.exe: 1 bytes of lfuse verified
avrdude.exe done. Thank you.
I had to reupload the blink sketch with a new (8Mhz) definition, + I changed the baud rate to 57600, not sure if the baud rate increases the upload speed, the new 8mhz is much faster (USBASP running in normal mode).
and reading the fuses reflects the new settings:
avrdude: safemode read 1, lfuse value: d2
avrdude: safemode read 2, lfuse value: d2
avrdude: safemode read 3, lfuse value: d2
avrdude: safemode: lfuse reads as D2
avrdude: safemode read 1, hfuse value: df
avrdude: safemode read 2, hfuse value: df
avrdude: safemode read 3, hfuse value: df
avrdude: safemode: hfuse reads as DF
avrdude: safemode read 1, efuse value: 1
avrdude: safemode read 2, efuse value: 1
avrdude: safemode read 3, efuse value: 1
avrdude: safemode: efuse reads as 1
avrdude: safemode: Fuses OK
contrary to popular belief its not necessary for usbasp to know what chip. a friend of mine ported a turboc 2.0 lpt program i wrote a long time ago to windows usbasp (poormans 'dude). just like my original utility it never cares what chip not does it check signatures to find out. the only burden on user is to tell flash size which is the only thing needed to program an avr properly.
avrdude by default does need user to specify type and then verifies signatures but in most cases this serves little purpose. except when flashing fuses it makes more sense to use -F. every time. i suspect one of the top gurus will be along shortly to accuse me of trolling but thats not the case (this time :)).
ok, here is how i'm thinking to set the fuses:
for reference here is the data sheet - http://www.atmel.com/images/doc2545.pdf
I will be using an external 16MHz crystal
Brown Out Detection 4.3V = BODLEVEL 100
Preserve EEPROM memory through the Chip Erase cycle; [EESAVE=0]
If I'm correct this option allows the data stored in EEPROM to be left untouched when you upload a new sketch/firmware, i.e. the erase procedure (before write) does not affect it.
The rest of the fuses are left untouched.
Here is the result from the fuses calculator AVR® Fuse Calculator – The Engbedded Blog :
-U lfuse:w:0xff:m -U hfuse:w:0xd4:m -U efuse:w:0xff:m
What do you guys think?
naut:
Here is the result from the fuses calculator AVR® Fuse Calculator – The Engbedded Blog :-U lfuse:w:0xff:m -U hfuse:w:0xd4:m -U efuse:w:0xff:m
What do you guys think?
The best "fuse calculator", by far, is the data sheet + your brain. Then you have the advantage of actually understanding what the numbers mean.
Your hfuse and efuse settings look ok, but your lfuse setting is completely wrong. For a start, you have an illegal value for SUT1-0. Leave it at the default value, or set to 00 if you are you are using BOD.
CKSEL3-0 are also wrong. You need to select full swing crystal oscillator. I know the correct values, having just looked at the datasheet, but I will leave it to you as an exercise to consult the datasheet yourself and calculate the correct lfuse value. You can post your calculation here to double check, but honestly, just don't mess with fuses unless you really understand what you are doing, rather than what the output of some "fuse calculator" tells you. It's not that hard! But you do need to read carefully. If there's some concept that you are not sure about, just ask. There will be plenty of knowledgeable people here to give you advice. (And a few not so knowledgeable, too. But you get what you pay for!
The thing is, if you know what you are doing, a "fuse calculator" is unnecessary. OTOH, if you don't know what you are doing, it won't help anyway. At best, they might be useful to double-check your calculations.
CKSEL3-0 are also wrong. You need to select full swing crystal oscillator.
I thought that the external crystal oscillator option will make the chip consume less power than the full swing option.
naut:
I thought that the external crystal oscillator option will make the chip consume less power than the full swing option.
It might well use less power. That would be the problem.
If I have BOD enabled (4.3V), will a slow/fast (4.1ms/65ms) rising edge of VCC on Power-on trigger a reset?
ok, I've done some calculations, here are the results:
High byte
1101 0111 = 0xdf
Low byte
1111 0111 = 0xf7
Full swing crystal oscillator enabled
Slowly rising power, 65ms + CK cycles
naut:
ok, I've done some calculations, here are the results:Extended byte
No changeHigh byte
1101 0111 = 0xdf
SPIEN - SPI programming enabled
EESAVE - EEPROM save enabled
BOD disabledLow byte
1111 0111 = 0xf7
Full swing crystal oscillator enabled
Slowly rising power, 65ms + CK cycles
That looks good. You've disabled BOD, and have the slow start SUT1-0 selection. That will work.
If you want to enable BOD, as you said you did originally, you could change hfuse to B0D enabled
hfuse = 1101 0100 = 0xd4 (as you had originally proposed)
and then select fastest start up with SUT1-0 = 01 (as per data sheet, table 9-6, p32)
lfuse = 1101 0111 = 0xd7
Either should work. Just what you prefer.
Well done! You now have the best and last fuse calculator you will ever need.