Does USBASP need to know what kind of MCU it's programming?

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=USBasp

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

atmega48.build.mcu=atmega48 atmega48.build.f_cpu=1000000L atmega48.build.core=arduino atmega48.build.variant=standard

so 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 http://www.engbedded.com/fusecalc/ 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

  1. Crystal Oscillator, slowly rising power, Start-up time from power-down and power-save - 16KCK Additional delay from reset (VCC = 5.0V) - 14CK + 65ms see Table 9-4, page 30-31

I will be using an external 16MHz crystal

  1. Brown Out Detection 4.3V = BODLEVEL 100

  2. 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.

  1. Serial program downloading (SPI) enabled; [SPIEN=0]

The rest of the fuses are left untouched.

Here is the result from the fuses calculator http://www.engbedded.com/fusecalc/ :

-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 http://www.engbedded.com/fusecalc/ :

-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:

Extended byte
No change

High byte

1101 0111 = 0xdf

SPIEN - SPI programming enabled
EESAVE - EEPROM save enabled
BOD disabled

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 change

High byte

1101 0111 = 0xdf

SPIEN - SPI programming enabled EESAVE - EEPROM save enabled

BOD disabled

Low 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.