-
-
Notifications
You must be signed in to change notification settings - Fork 23
lock/unlock bits fail to verify with Atmel AVRISP mkII and avrdude 6.3.0-arduino2 #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This issue is addressed in arduino/Arduino#5202 |
Patch submitted at https://savannah.nongnu.org/patch/index.php?9110 |
@facchinm, I think this patch still has some pointless code (as pointed out by @descampsa in this comment) that should be simplified. I'd like to prod upstream about this patch, but not until this improvement is made to the patch. Here's how I think it should look.
This code should be in place of the current @facchinm, could you try and test this change and if it works, replace the upstream patch? |
I went ahead and made the changes I suggested above, the changes I suggested here as well as some other improvements (most notably, the warning message shown is now different when the user did actually supply ones for unused bits, but the programmer returns zeroes for them). I uploaded the new patch upstream: https://savannah.nongnu.org/patch/index.php?9110 |
@matthijskooijman sure, I'll test it asap |
@facchinm, I guess you never got around to this? Might be good to use my improved patch in a new avrdude build, mainly since it improves the warning shown when we change the lock bytes (see arduino/Arduino#6601) and might be reason for upstream to merge it too... |
It seems my patch got merged by avrdude upstream a few days ago: https://savannah.nongnu.org/patch/index.php?9110#comment2 Maybe it would be good to update the avrdude version to the latest git version, or at least update the patch to the latest version (or update to a new release if it would be released soon, I've asked in the patch tracker about this)? |
Just as a heads-up, The avrdude project has now migrated over to Github: https://github.com/avrdudes/avrdude |
Using Arduino IDE 1.6.10/Arduino AVR Boards 1.6.12 with Windows 7 64 and 32 bit
The operation fails:
The same issue occurs with all the Arduino AVR Boards I tested (every ATmega328P, ATmega168, ATmega32U4, and ATmega2560 based board in boards.txt) except for Gemma (which is unaffected by this issue or the patch).
Using the same programmer with avrdude 6.0.1-arduino5 works correctly.
The issue is caused by:
http://savannah.nongnu.org/bugs/?46759
It is fixed by modifying avrdude.conf according to this patch:
https://savannah.nongnu.org/patch/index.php?8996
I applied the patch to the "Arduino AVR Boards" platform 1.6.12
avrdude.conf
(attached:avrdude.conf.txt
) and modified theunlock_bits
andlock_bits
inboards.txt
(attached:boards.txt
), which hasextended_fuses
values also modified according to arduino/Arduino#5182.With those modifications in place, I did a Tools > Burn Bootloader on every ATmega328P, ATmega168, ATmega32U4, ATmega2560 based board in
boards.txt
using Atmel AVRISP mkII, USBasp, Arduino as ISP and USBtinyISP. I was unable to completely test thelock_bits
with my USBtinyISP because it's been failing verification of larger hex files lately for some reason but that issue is happening universally and so is not specific to this test or avrdude 6.3.0-arduino2. I was able to successfully burn ATmega328P and ATmega168 based boards with the USBtinyISP.The disadvantage I see to applying the patch to
avrdude.conf
is this will break any 3rd party boards platforms that use the affected MCUs and Arduino'savrdude.conf
. In order to fix this and maintain backwards compatibility with previous Arduino AVR Boards versions they will need to specify their ownavrdude
tool (EDIT: I had assumed this patch required a recent AVRDUDE version but this may not be the case?) in the JSON file, as well as include it with manual installation files, and include their ownavrdude.conf
file. Some of these packages will already need to do this due to arduino/Arduino#5175.The text was updated successfully, but these errors were encountered: