bugAVR Downloader/UploaDEr - Bugs: bug #49898, Config file error for many parts

 
 

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

bug #49898: Config file error for many parts

Submitter:  Owen Duffy <owenduffy>
Submitted:  Wed 21 Dec 2016 03:11:01 AM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Duplicate Privacy:  Public
Assigned to:  None Originator Name:  Owen
Open/Closed:  Open Release:  6.3
Programmer hardware:  USBASP Device type:  m328

Wed 21 Dec 2016 01:04:46 PM UTC, comment #2: 

I read most of the long discussion.

For as long as I can remember, the Atmel tools have required the user to specify ONLY the implemented bits for the example case I gave, three bits. They do not state in the datasheet that the user must specify unimplemented bits at 1, but they do hint that they will read back as one (because being unimplemented, the should always be 'unprogrammed'.

In Atmel's tools if I select BOD=2.7 from the feature selection, it calculates and shows efuse=0x05, and if programmed, that WILL verify.

That is all rational.

It seems that recently, AVRDUDE's direction is to mask out ONLY three bits from user supplied efuse parm (for this part), but include 8 bits read back from the part for verification. Why verify bits that the user did not specify.

AVRDUDE has changed to strike out on its own, it requires a different efuse specification than the Atmel tools display... not for programming the fuse correctly, but purely for verification.

Most tools follow Atmel's lead, eg http://www.engbedded.com/fusecalc/ .

I think you have made a mistake, the solution for users who want consistency with Atmel and compatibility with all the existing scripts, makefiles and project documentation seems to be v6.1.

Owen Duffy <owenduffy>
Wed 21 Dec 2016 09:27:50 AM UTC, comment #1: 

This seems to be a duplicate of bug #22248 to me.

Joerg Wunsch <joerg_wunsch>
Group administrator
Wed 21 Dec 2016 03:11:01 AM UTC, original submission:  

Verify error setting efuse to 0x05.

It seems that the config file contains:
memory "efuse"
    size = 1;
    min_write_delay = 4500;
    max_write_delay = 4500;
    read = "0 1 0 1 0 0 0 0 0 0 0 0 1 0 0 0",
           "x x x x x x x x o o o o o o o o";

    write = "1 0 1 0 1 1 0 0 1 0 1 0 0 1 0 0",
              "x x x x x x x x x x x x x i i i";
    ;

Which I think causes it to write 0x05, and read back 8 bits incl unimplemented bits as report as 0xfd which of course does not verify.

This looks like a global change that has messed up lots of the config file, do a diff with v6.1 and you will not what has happened.

Meanwhile, 6.1 looks the best version out there.

Owen

Owen Duffy <owenduffy>

 

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

No files currently attached

 

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 owenduffy (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.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-12-21 joerg_wunsch StatusNone Duplicate

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code