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

Submitted by:  Owen Duffy <owenduffy>
Submitted on:  Wed 21 Dec 2016 03:11:01 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: None
Status: DuplicatePrivacy: Public
Assigned to: NoneOriginator Name: Owen
Open/Closed: OpenRelease: 6.3
Programmer hardware: USBASPDevice 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>
Project 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>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 21 Dec 2016 09:27:50 AM UTCjoerg_wunschStatusNone=>Duplicate

    Back to the top


    Powered by Savane 3.1-cleanup1