AVR 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: |
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>![]() |
Wed 21 Dec 2016 03:11:01 AM UTC, original submission:
Verify error setting efuse to 0x05.
|
Owen Duffy <owenduffy> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
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 | Status | None | ![]() |
Duplicate |
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.