bugAVR Downloader/UploaDEr - Bugs: bug #22248, Read efuse error

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #22248: Read efuse error

Submitter:  None
Submitted:  Thu 07 Feb 2008 09:21:31 AM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Invalid Privacy:  Public
Assigned to:  joerg_wunsch Originator Name:  SimonQian
Originator Email:  -email is unavailable- Open/Closed:  Open
Release:  None Programmer hardware: 
Device type: 

Mon 06 Oct 2014 01:39:11 PM UTC, comment #2: 

I implemented a partial fix, by unifying the behaviour between
different AVRs.  Thus, for the following devices, the efuse
definition has been changed to no longer mask off bits in
output:

m168, m328, m48, m88, t1634, t26, t261, t461, t861, t88

(For t26, it's actually hfuse rather than efuse.)

Not touching the following historic devices:

2333, 4433, 4434, 8535, m103, m161, m163

For these devices, the fuses are not documented to form a full
byte, and the bit definitions for reading and writing them are
rather obscure.  Thus, avrdude.conf.in better keeps conforming
to what is written in those datasheets.

Not yet done: turning all bits that are marked "x" when
writing into "don't care" when comparing them.

Joerg Wunsch <joerg_wunsch>
Group administrator
Thu 07 Feb 2008 09:52:05 AM UTC, comment #1: 

You don't write which AVR this is about.  As the JTAG ICE
did return the 0xf8 correctly, it's very likely that all
the 5 high-order bits are simply marked "reserved" for your
AVR, so AVRDUDE masks them off when displaying.

It's somewhat questionable whether masking them off should
display the masked bits as 1 (because that's the default
value of an unprogrammed EEPROM bit) or 0 as it is now
(because that's what looks more logically for masking
something off).

So essentially, this is not a bug at all.

When browsing avrdude.conf, I noticed that we are currently
not very consistent about the unused bits in efuse.  Some
devices always read (and display) 8 bits including the
unused ones, and only mask bits off when writing.  Other
devices (like the ATmega88/168 you are perhaps using)
apply the mask as applicable for the respective device even
when reading.  We should probably make that consistent.
I'll just leave the bug report open for this as a reminder.

This is somewhat related to bug #21954.

Joerg Wunsch <joerg_wunsch>
Group administrator
Thu 07 Feb 2008 09:21:31 AM UTC, original submission:  

I tried to read fuses bits in avrdude, and both lfuse and hfuse are OK under safemode, but efuse is read as 0.

Reading lfuse:
avrdude: jtagmkII_send(): sending 11 bytes
avrdude: Sent: . [1b] . [0b] . [00] . [0b] . [00] . [00] . [00] . [0e] / [2f] . [07] . [00] . [1d] . [04] . [04] . [00] P [50] . [00] . [00] . [00] . [eb] . [b5]
avrdude: jtagmkII_recv():
avrdude: Recv: . [1b]
avrdude: Recv: . [0b]
avrdude: Recv: . [00]
avrdude: Recv: . [08]
avrdude: Recv: . [00]
avrdude: Recv: . [00]
avrdude: Recv: . [00]
avrdude: Recv: . [0e]
avrdude: Recv: . [88] . [1d] . [00] . [00] P [50] . [00] . [ff] . [00]
avrdude: Recv: . [84]
avrdude: Recv: . [13]
avrdude: jtagmkII_recv(): CRC OK
avrdude: jtagmkII_recv(): Got message seqno 11 (command_sequence == 11)
avrdude: safemode read 3, lfuse value: ff
avrdude: safemode: lfuse reads as FF

Reading hfuse:
avrdude: jtagmkII_send(): sending 11 bytes
avrdude: Sent: . [1b] . [0c] . [00] . [0b] . [00] . [00] . [00] . [0e] / [2f] . [07] . [00] . [1d] . [04] . [04] . [00] X [58] . [08] . [00] . [00] f [66] l [6c]
avrdude: jtagmkII_recv():
avrdude: Recv: . [1b]
avrdude: Recv: . [0c]
avrdude: Recv: . [00]
avrdude: Recv: . [08]
avrdude: Recv: . [00]
avrdude: Recv: . [00]
avrdude: Recv: . [00]
avrdude: Recv: . [0e]
avrdude: Recv: . [88] . [1d] . [00] . [00] X [58] . [08] . [dc] . [00]
avrdude: Recv: . [02]
avrdude: Recv: . [c9]
avrdude: jtagmkII_recv(): CRC OK
avrdude: jtagmkII_recv(): Got message seqno 12 (command_sequence == 12)
avrdude: safemode read 1, hfuse value: dc

Reading efuse:
avrdude: jtagmkII_send(): sending 11 bytes
avrdude: Sent: . [1b] . [0f] . [00] . [0b] . [00] . [00] . [00] . [0e] / [2f] . [07] . [00] . [1d] . [04] . [04] . [00] P [50] . [08] . [00] . [00] . [86] . [88]
avrdude: jtagmkII_recv():
avrdude: Recv: . [1b]
avrdude: Recv: . [0f]
avrdude: Recv: . [00]
avrdude: Recv: . [08]
avrdude: Recv: . [00]
avrdude: Recv: . [00]
avrdude: Recv: . [00]
avrdude: Recv: . [0e]
avrdude: Recv: . [88] . [1d] . [00] . [00] P [50] . [08] . [f8] . [00]
avrdude: Recv: . [f7]
avrdude: Recv: . [b0]
avrdude: jtagmkII_recv(): CRC OK
avrdude: jtagmkII_recv(): Got message seqno 15 (command_sequence == 15)
avrdude: safemode read 1, efuse value: 0
It should be 0xf8 according to the data returned, but avrdude displays 0.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #14983:  info.log added by None (28KiB - text/x-log)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by joerg_wunsch (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-04-18 joerg_wunsch PrivacyPrivate Public
    2008-02-07 joerg_wunsch StatusNone Invalid
        Assigned toNone joerg_wunsch
    2008-02-07 None Attached File- Added info.log, #14983

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code