Arduino Fuse bits might be causing the quirky firmware upload issues


#1

So the topic of fuses is a newer one for me. Apparently this goes a long way in affecting how the Arduino boot loader responds. My initial read of the fuses looks alarmingly like they have not been programmed from the factory. Based on what I have read so far, we should expect thing like the clock selection to actually be referencing and external crystal vs a clock based on our cape design.

I am including a screen shot of what options are set based on the current 0x0 bytes that appear to be set at the moment. This is from a fuse calculator. I'd love someone that has more experience on embedded systems to weigh in and let me know if my assessment is plausible or way off.

Below is also the raw commands and output from avrdude when reading the fuse bits. You should be able to do the same by doing the following commands one after the other from the ROV. It is always possible I'm getting bogus results but the commands do appear correct:

sudo /opt/openrov/linux/reset.sh

avrdude -v -c arduino -P /dev/ttyO1 -p m328p -U lfuse:r:-:h -U hfuse:r:-:h -U efuse:r:-:h -U lock:r:-:h


rov@OpenROV:~$ avrdude -v -c arduino -P /dev/ttyO1 -p m328p -U lfuse:r:-:h -U hfuse:r:-:h -U efuse:r:-:h -U lock:r:-:h
avrdude: Version 5.11.1, compiled on Dec 7 2011 at 20:56:43
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch

System wide configuration file is "/etc/avrdude.conf"
User configuration file is "/home/rov/.avrduderc"
User configuration file does not exist or is not a regular file, skipping

Using Port : /dev/ttyO1
Using Programmer : arduino
AVR Part : ATMEGA328P
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 : Arduino
Description : Arduino
Hardware Version: 3
Firmware Version: 4.4
Vtarget : 0.3 V
Varef : 0.3 V
Oscillator : 28.800 kHz
SCK period : 3.3 us

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e950f
avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: efuse reads as 0
avrdude: reading lfuse memory:

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

avrdude: writing output file "<stdout>"
0x0
avrdude: reading hfuse memory:

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

avrdude: writing output file "<stdout>"
0x0
avrdude: reading efuse memory:

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

avrdude: writing output file "<stdout>"
0x0
avrdude: reading lock memory:

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

avrdude: writing output file "<stdout>"
0x0

avrdude: safemode: lfuse reads as 0
avrdude: safemode: hfuse reads as 0
avrdude: safemode: efuse reads as 0
avrdude: safemode: Fuses OK

avrdude done. Thank you.


#2

This seems to confirm that the serial programmers cannot read the fuse settings. Would anyone that has another type of programmer be willing to verify the fuze settings?


#3

And for those that want an overview on why fuses matter and the different ways an Arduino can be programmed: http://www.gammon.com.au/forum/?id=11643