Compile problems, avrdude for mac.

Log in or register to post comments
Go To Last Post
27 posts / 0 new
Author
Message
gigante
gigante's picture
Level: New Member
Joined: Fri. Sep 9, 2011
Posts: 13 View posts
#1
Posted by gigante: Fri. Jan 23, 2015 - 01:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've done my best searching for an answer to this question:

I am using avrdude for Mac using Crosspack.

 

I have added the atmega328 to my config file, and when I ask avrdude what micros it knows, the 328 appears at the top of the list.

 avrdude -p?

Valid parts are:
  m328 = ATMEGA328       [/usr/local/etc/avrdude.conf:10964]
  m6450 = ATMEGA6450      [/usr/local/etc/avrdude.conf:10774]
  m3250 = ATMEGA3250      [/usr/local/etc/avrdude.conf:10585]
  m645 = ATMEGA645       [/usr/local/etc/avrdude.conf:10396]
  
  ...

I am able to program to the chip. I know my hardware is good. The board works (mostly) when programmed by the original creator of the project, but I cannot change the code and compile. When I try, I get the "unknown MCU" message and the 328 doesn't appear among the known MCUs.

avr-gcc -g -Wall -O2 -mmcu=atmega328 -fno-exceptions -ffunction-sections -fdata-sections -I.././lunchbeat-pcb -c lunchbeat-pcb.c 
unknown MCU 'atmega328' specified
Known MCU names:
   avr2
   at90s2313
   at90s2323
   at90s2333
   ...

Anybody have any suggestions for something to try?

This topic has a solution.

Tags:

Tools, Compilers and General Programming
Top
ezharkov
ezharkov's picture
Level: Posting Freak
Joined: Tue. Jun 21, 2005
Posts: 1427 View posts
Location: Chicago area, USA
Posted by ezharkov: Fri. Jan 23, 2015 - 01:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You must have a very ancient avr-gcc. What does "avr-gcc -v" say?

Top
Koshchi
Koshchi's picture
Level: 10k+ Postman
Joined: Wed. Nov 17, 2004
Posts: 15658 View posts
Location: Vancouver, BC
Posted by Koshchi: Fri. Jan 23, 2015 - 01:28 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

First, avrdude knows nothing about compiling. The compiler is avr-gcc.

 

Second, what version of avr-gcc are you using?

Regards,
Steve A.

The Board helps those that help themselves.

Top
gigante
gigante's picture
Level: New Member
Joined: Fri. Sep 9, 2011
Posts: 13 View posts
Posted by gigante: Fri. Jan 23, 2015 - 01:33 AM (Reply to #3)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
 avr-gcc -v
Using built-in specs.
Target: avr
Configured with: ./configure --target=avr --enable-languages=c,c++ --disable-nls --disable-libssp --prefix=/usr/local/staging.avr-gcc
Thread model: single
gcc version 4.1.1

 

Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 4780 View posts
Location: SF Bay area
Posted by westfw: Fri. Jan 23, 2015 - 02:30 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Get this: http://www.obdev.at/products/cro...

The 2010 version is approximately equivalent to the last "winavr" package.

The latest version should be approximately equivalent to the current Atmel tools.

 

Top
gigante
gigante's picture
Level: New Member
Joined: Fri. Sep 9, 2011
Posts: 13 View posts
Posted by gigante: Fri. Jan 23, 2015 - 03:32 AM (Reply to #5)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I initially installed from "CrossPack-AVR-20131216.dmg", which says it should have "Avr-gcc in version 4.8.1.". I tried installing again, and then checked and I still have gcc version 4.1.1. Is there a way to manually update gcc?

 

Thanks for the help so far.

Top
mnehpets
mnehpets's picture
Level: Resident
Joined: Wed. Nov 9, 2011
Posts: 963 View posts
Posted by mnehpets: Fri. Jan 23, 2015 - 07:23 AM (Reply to #6)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gigante wrote:

I initially installed from "CrossPack-AVR-20131216.dmg", which says it should have "Avr-gcc in version 4.8.1.". I tried installing again, and then checked and I still have gcc version 4.1.1. Is there a way to manually update gcc?

Have you put /usr/local/CrossPack-AVR/bin in your PATH? What's the value of $PATH?

 

What is the output of this command:

/usr/local/CrossPack-AVR/bin/avr-gcc -v

- S

 

Last Edited: Fri. Jan 23, 2015 - 07:24 AM
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101134 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Jan 23, 2015 - 02:49 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you considered installing a virtual machine (do they do "VirtualBox" for Mac?) and then installing some well known Linux into it? In that case you could just "Atmel toolchain for Linux" or similar to give you a fairly recent 4.8.1.

 

EDIT: just answered my own question:

 

http://www.tuaw.com/2009/09/07/h...

Top
gigante
gigante's picture
Level: New Member
Joined: Fri. Sep 9, 2011
Posts: 13 View posts
Posted by gigante: Fri. Jan 23, 2015 - 03:09 PM (Reply to #8)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mnehpets wrote:

 

Have you put /usr/local/CrossPack-AVR/bin in your PATH? What's the value of $PATH?

 

What is the output of this command:

/usr/local/CrossPack-AVR/bin/avr-gcc -v

- S

 

 

I will let you know when I get home from work.

 

Edit: Excuse my ignorance, but will the response to "/usr/local/CrossPack-AVR/bin/avr-gcc -v" answer the question "Have you put /usr/local/CrossPack-AVR/bin in your PATH? What's the value of $PATH?"

 

clawson wrote:

Have you considered installing a virtual machine (do they do "VirtualBox" for Mac?) and then installing some well known Linux into it? In that case you could just "Atmel toolchain for Linux" or similar to give you a fairly recent 4.8.1.

 

EDIT: just answered my own question:

 

http://www.tuaw.com/2009/09/07/how-to-set-up-ubuntu-linux-on-a-mac-its-easy-and-free/

 

I haven't tried that option. I don't have any experience running linux. If I can't get running with crosspack, I may go that direction. The link you sent looks pretty straightforward. Thanks.

Last Edited: Fri. Jan 23, 2015 - 03:11 PM
Top
Gold Markclawson
clawson's picture
Level: Moderator
Joined: Mon. Jul 18, 2005
Posts: 101134 View posts
Location: (using avr-gcc in) Finchingfield, Essex, England
Posted by clawson: Fri. Jan 23, 2015 - 03:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

but will the response to "/usr/local/CrossPack-AVR/bin/avr-gcc -v" answer the question "Have you put /usr/local/CrossPack-AVR/bin in your PATH?

Nope that just ensures the PATH is ignored and a specific version of the program is run from a known location. If you do want to check the path I imagine something like:

$ env | grep -w PATH
PATH=/usr/lib/lightdm/lightdm:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

will work. (that's showing what my (Linux) path is set to).

Top
gigante
gigante's picture
Level: New Member
Joined: Fri. Sep 9, 2011
Posts: 13 View posts
Posted by gigante: Fri. Jan 23, 2015 - 10:46 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here are the responses to the commands:

 

$ env | grep -w PATH

PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/CrossPack-AVR/bin:/usr/local/bin:/usr/local/bin

 

$ /usr/local/CrossPack-AVR/bin/avr-gcc -v

Using built-in specs.
COLLECT_GCC=/usr/local/CrossPack-AVR/bin/avr-gcc
COLLECT_LTO_WRAPPER=/usr/local/CrossPack-AVR-20131216/libexec/gcc/avr/4.8.1/lto-wrapper
Target: avr
Configured with: ../configure --prefix=/usr/local/CrossPack-AVR-20131216 --disable-dependency-tracking --disable-nls 
--disable-werror --target=avr --enable-languages=c,c++ --disable-libssp --disable-libada --with-dwarf2 --disable-shared 
--with-avrlibc=yes --with-gmp=/Users/cs/Developer/Repos/Microcontroller/CrossPack-AVR/temporary-install 
--with-mpfr=/Users/cs/Developer/Repos/Microcontroller/CrossPack-AVR/temporary-install 
--with-mpc=/Users/cs/Developer/Repos/Microcontroller/CrossPack-AVR/temporary-install
Thread model: single
gcc version 4.8.1 (GCC)

 

Top
mnehpets
mnehpets's picture
Level: Resident
Joined: Wed. Nov 9, 2011
Posts: 963 View posts
This reply has been marked as the solution. 
Posted by mnehpets: Sat. Jan 24, 2015 - 12:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You have an up to date crosspack installed, but you also have some older version of the avr tools installed somewhere (I'm guessing in /usr/local), and because /usr/local/bin appears in PATH before /usr/local/CrossPack-AVR/bin, whenever you run avrdude or avr-gcc, you're getting that older version. Try setting PATH to:

PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/CrossPack-AVR/bin:/usr/local/bin

- S

 

Top
gigante
gigante's picture
Level: New Member
Joined: Fri. Sep 9, 2011
Posts: 13 View posts
Posted by gigante: Sat. Jan 24, 2015 - 01:01 AM (Reply to #12)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perfect. It works! Thanks for all the help. Now if only my crystal would work (Hopefully because I have 22pF caps where I should have 20pF.)

Last Edited: Sat. Jan 24, 2015 - 01:00 AM
Top
joeymorin
joeymorin's picture
Level: 10k+ Postman
Joined: Tue. Jul 17, 2012
Posts: 12051 View posts
Location: Location, Location
Posted by joeymorin: Sat. Jan 24, 2015 - 02:23 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gigante wrote:

Perfect. It works! Thanks for all the help. Now if only my crystal would work (Hopefully because I have 22pF caps where I should have 20pF.)

Have you used avrdude to change the fuses to enable the crystal oscillator?  If you don't know what I mean, don't just go off and do it.  Incorrect fuse settings can 'brick' and AVR.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Top
gigante
gigante's picture
Level: New Member
Joined: Fri. Sep 9, 2011
Posts: 13 View posts
Posted by gigante: Mon. Jan 26, 2015 - 01:21 PM (Reply to #14)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have set the fuse for external clock, but it just runs slowly, as if it is still using the internal clock. Can I brick it only changing the low fuse byte?

Top
joeymorin
joeymorin's picture
Level: 10k+ Postman
Joined: Tue. Jul 17, 2012
Posts: 12051 View posts
Location: Location, Location
Posted by joeymorin: Mon. Jan 26, 2015 - 03:08 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
but it just runs slowly
How slowly?

 

My first guess is you still have CKDIV8 programmed.  Have you run a simple 1-second-on,-1-second-off LED flash test program?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Top
gigante
gigante's picture
Level: New Member
Joined: Fri. Sep 9, 2011
Posts: 13 View posts
Posted by gigante: Tue. Jan 27, 2015 - 03:17 AM (Reply to #16)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I just checked. I can run a blinking light, but only by including "#define F_CPU 1000000UL" which to me means the CKDIV8 is on and using the internal 8MHz clock. When I try to change the fuses, and I get back the following no matter what I change the low byte to (and with high fuse set to d9):

avrdude: safemode: Fuses OK (H:07, E:D9, L:62)

 

Top
joeymorin
joeymorin's picture
Level: 10k+ Postman
Joined: Tue. Jul 17, 2012
Posts: 12051 View posts
Location: Location, Location
Posted by joeymorin: Tue. Jan 27, 2015 - 04:31 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Show your full avrdude session console output.
 

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Top
gigante
gigante's picture
Level: New Member
Joined: Fri. Sep 9, 2011
Posts: 13 View posts
Posted by gigante: Wed. Jan 28, 2015 - 02:32 AM (Reply to #18)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use this makefile:

 

PRG            = LED
OBJ            = LED.o 
INCLUDE_PATH   = -I.././LED

COMPILE_TARGET = atmega328
UPLOAD_TARGET  = atmega328
PROGRAMMER     = avrisp2
LFUSE          = 0xc4
HFUSE          = 0xd9

upload: $(PRG).hex 
	avrdude -c $(PROGRAMMER) -P usb -p $(UPLOAD_TARGET) -U flash:w:$(PRG).hex

a: $(PRG).elf lst hex

$(PRG).elf: $(OBJ)
	avr-gcc -g -Wall -mmcu=$(COMPILE_TARGET) -o $@ $^ 

%.o: %.c
	avr-gcc -g -Wall -O2 -mmcu=$(COMPILE_TARGET) -fno-exceptions -ffunction-sections -fdata-sections $(INCLUDE_PATH) -c $< 

lst:  $(PRG).lst
%.lst: %.elf
	avr-objdump -h -S $< > $@

hex:  $(PRG).hex
%.hex: %.elf
	avr-objcopy -j .text -j .data -O ihex $< $@

clean:
	rm -rf *.o $(PRG).elf *.lst *.hex

setfuses:
	avrdude -c $(PROGRAMMER) -p $(UPLOAD_TARGET) -U lfuse:w:$(LFUSE):m
	avrdude -c $(PROGRAMMER) -p $(UPLOAD_TARGET) -U hfuse:w:$(HFUSE):m

and get this response:

avr-gcc -g -Wall -O2 -mmcu=atmega328 -fno-exceptions -ffunction-sections -fdata-sections -I.././LED -c LED.c 
avr-gcc -g -Wall -mmcu=atmega328 -o LED.elf LED.o 
avr-objcopy -j .text -j .data -O ihex LED.elf LED.hex
avrdude -c avrisp2 -P usb -p atmega328 -U flash:w:LED.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9514
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "LED.hex"
avrdude: input file LED.hex auto detected as Intel Hex
avrdude: writing flash (182 bytes):

Writing | ################################################## | 100% 0.06s

avrdude: 182 bytes of flash written
avrdude: verifying flash memory against LED.hex:
avrdude: load data flash data from input file LED.hex:
avrdude: input file LED.hex auto detected as Intel Hex
avrdude: input file LED.hex contains 182 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.08s

avrdude: verifying ...
avrdude: 182 bytes of flash verified

avrdude: safemode: Fuses OK (H:07, E:D9, L:62)

avrdude done.  Thank you.

 

Top
gigante
gigante's picture
Level: New Member
Joined: Fri. Sep 9, 2011
Posts: 13 View posts
Posted by gigante: Wed. Jan 28, 2015 - 03:08 AM (Reply to #19)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I tried to program the fuses using

avrdude -c avrisp2 -p atmega328 -U hfuse:w:0xD9:m

and

avrdude -c avrisp2 -p atmega328 -U lfuse:w:0xFF:m

 

When I ran my program again, it runs at correct speed. It's still not using the external crystal, but instead this command is now working where it didn't before:

#define F_CPU 1000000UL

I'm still getting the fuses not changing, as seen above and again here below:

avrdude -c avrisp2 -P usb -p atmega328 -U flash:w:lunchbeat-pcb.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9514
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "lunchbeat-pcb.hex"
avrdude: input file lunchbeat-pcb.hex auto detected as Intel Hex
avrdude: writing flash (3028 bytes):

Writing | ################################################## | 100% 0.94s

avrdude: 3028 bytes of flash written
avrdude: verifying flash memory against lunchbeat-pcb.hex:
avrdude: load data flash data from input file lunchbeat-pcb.hex:
avrdude: input file lunchbeat-pcb.hex auto detected as Intel Hex
avrdude: input file lunchbeat-pcb.hex contains 3028 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.91s

avrdude: verifying ...
avrdude: 3028 bytes of flash verified

avrdude: safemode: Fuses OK (H:07, E:D9, L:FF)

avrdude done.  Thank you.

 

Top
joeymorin
joeymorin's picture
Level: 10k+ Postman
Joined: Tue. Jul 17, 2012
Posts: 12051 View posts
Location: Location, Location
Posted by joeymorin: Wed. Jan 28, 2015 - 04:06 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your makefile doesn't touch the fuses unless you run it against the  setfuses target, and your typescript shows that you didn't, so it's not surprising that they didn't change.

 

You didn't show the full avrdude session console output for your fuse commands (which you appeared to run manually) as you were asked, so I can't be sure what happened.  However:

 

Quote:
I'm still getting the fuses not changing, as seen above and again here below:
Are you sure about that?:

avrdude: safemode: Fuses OK (H:07, E:D9, L:FF)

Looks to me as though the low fuse was in fact changed just like you asked:

avrdude -c avrisp2 -p atmega328 -U lfuse:w:0xFF:m

However it looks like the extended fuse has taken on the value of the high fuse.  This is not really true however.  IIRC one of the recent releases of avrude has a bug whereby the fuse report at the end of a session transposes the high and extended fuses, so this:

avrdude: safemode: Fuses OK (H:07, E:D9, L:FF)

... actually means this:

avrdude: safemode: Fuses OK (E:07, H:D9, L:FF)

Your AVR now expects a crystal and caps on XTAL1/2.

 

What frequency is the external crystal are you using?  Are you sure that your tests with F_CPU 1000000UL were done after the low fuse was successfully changed?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Last Edited: Wed. Jan 28, 2015 - 04:09 AM
Top
gigante
gigante's picture
Level: New Member
Joined: Fri. Sep 9, 2011
Posts: 13 View posts
Posted by gigante: Wed. Jan 28, 2015 - 01:54 PM (Reply to #21)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

joeymorin wrote:

Your makefile doesn't touch the fuses unless you run it against the  setfuses target, and your typescript shows that you didn't, so it's not surprising that they didn't change.

 

You didn't show the full avrdude session console output for your fuse commands (which you appeared to run manually) as you were asked, so I can't be sure what happened.  However:

 

 

In my first reply, I did post everything (as I understood what you were asking for?) but I also thought I was changing the fuses with the last part of the makefile. I didn't realize that wasn't working. I will post the results of the setfuse lines when I get home tonight.

 

joeymorin wrote:

 

Are you sure about that?:

 

 

avrdude: safemode: Fuses OK (H:07, E:D9, L:FF)

Looks to me as though the low fuse was in fact changed just like you asked:

 

avrdude -c avrisp2 -p atmega328 -U lfuse:w:0xFF:m

However it looks like the extended fuse has taken on the value of the high fuse.  This is not really true however.  IIRC one of the recent releases of avrude has a bug whereby the fuse report at the end of a session transposes the high and extended fuses, so this:

avrdude: safemode: Fuses OK (H:07, E:D9, L:FF)

... actually means this:

avrdude: safemode: Fuses OK (E:07, H:D9, L:FF)

Your AVR now expects a crystal and caps on XTAL1/2.

 

 

It looks like you are correct. I think I was just looking at the high and didn't notice the low had actually changed.

 

joeymorin wrote:

 

What frequency is the external crystal are you using?  Are you sure that your tests with F_CPU 1000000UL were done after the low fuse was successfully changed?

 

16MHz. What i'm thinking now instead is that if it is actually using the crystal, the F_CPU command didn't actually work. Or, I may have changed it back. I will have to take a look again when I get home.

 

Thanks again for your patience and all your help as I try to learn this stuff.

Last Edited: Wed. Jan 28, 2015 - 01:55 PM
Top
joeymorin
joeymorin's picture
Level: 10k+ Postman
Joined: Tue. Jul 17, 2012
Posts: 12051 View posts
Location: Location, Location
Posted by joeymorin: Wed. Jan 28, 2015 - 07:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The makefile does have a provision for programming the fuses, but you have to call make with the correct target:
make setfuses
Just so you know, F_CPU isn't a command. It is a macro. After it is defined, the C preprocessor wil replace all instances of F_CPU with 1000000UL (or whatever you defined it as). This is so that code which relies on knowledge of the CPU clock (like delays and timer init code) can do the math correctly. If F_CPU doesn't reflect reality, timing in you app won't either.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Top
gigante
gigante's picture
Level: New Member
Joined: Fri. Sep 9, 2011
Posts: 13 View posts
Posted by gigante: Fri. Jan 30, 2015 - 01:41 AM (Reply to #23)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrdude -c avrisp2 -p atmega328 -U lfuse:w:0xFF:m

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9514
avrdude: reading input file "0xFF"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xFF:
avrdude: load data lfuse data from input file 0xFF:
avrdude: input file 0xFF contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified

avrdude: safemode: Fuses OK (H:07, E:D9, L:FF)

avrdude done.  Thank you.

avrdude -c avrisp2 -p atmega328 -U hfuse:w:0xD9:m

vrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9514
avrdude: reading input file "0xD9"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xD9:
avrdude: load data hfuse data from input file 0xD9:
avrdude: input file 0xD9 contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified

avrdude: safemode: Fuses OK (H:07, E:D9, L:FF)

avrdude done.  Thank you.

I checked on the F_CPU macro and I am still using "#define F_CPU 1000000UL". It doesn't make a difference when I change it to "#define F_CPU 16000000UL".

Top
larryvc
larryvc's picture
Level: Raving Lunatic
Joined: Thu. Dec 6, 2007
Posts: 4229 View posts
Location: Redmond, WA, USA
Posted by larryvc: Fri. Jan 30, 2015 - 02:15 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can you post the version of avrdude that is shown when this command is run?  I may be wrong, but I feel you are running an old version.

avrdude -c avrisp2 -p atmega328 -v

 

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

Top
gigante
gigante's picture
Level: New Member
Joined: Fri. Sep 9, 2011
Posts: 13 View posts
Posted by gigante: Fri. Jan 30, 2015 - 02:55 AM (Reply to #25)
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrdude -c avrisp2 -p atmega328 -v

avrdude: Version 6.0.1, compiled on Dec 16 2013 at 17:26:24
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "/usr/local/CrossPack-AVR-20131216/etc/avrdude.conf"
         User configuration file is "/Users/csp/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : usb
         Using Programmer              : avrisp2
avrdude: usbdev_open(): Found AVRISP mkII, serno: 000200136931
         AVR Part                      : ATmega328
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : STK500V2
         Description     : Atmel AVR ISP mkII
         Programmer Model: AVRISP mkII
         Hardware Version: 1
         Firmware Version Master : 1.10
         Vtarget         : 5.0 V
         SCK period      : 8.00 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9514
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as 7

avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D9
avrdude: safemode: efuse reads as 7
avrdude: safemode: Fuses OK (H:07, E:D9, L:FF)

avrdude done.  Thank you.

 

Top
joeymorin
joeymorin's picture
Level: 10k+ Postman
Joined: Tue. Jul 17, 2012
Posts: 12051 View posts
Location: Location, Location
Posted by joeymorin: Fri. Jan 30, 2015 - 04:50 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's a pretty recent version, but IIRC 6.0.1 is the one that suffered from the high/extended transposition bug when reporting fuses at the end of a session (as mentioned above).

 

You have indeed correctly set the fuses to:

e:0x07

h:0xD9

l:0xFF

 

If changing F_CPU has no effect, then it's likely that it is defined elsewhere.

 

Post the whole of your code.  If it's too large to post or is 'secret', then you'll need to compose a complete test program which exhibits the behaviour you're seeing.  Often in the process of so doing you will spot the problem yourself.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

Top