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

Problem with avrdude for bootloader upload to atmega328 #5175

Closed
descampsa opened this Issue Jul 28, 2016 · 13 comments

Comments

7 participants
@descampsa
Contributor

descampsa commented Jul 28, 2016

When trying to upload the bootloader to my Arduino Uno board, avrdude fails (see attached log).

The reason seems to be that the extended fuse byte is not read correctly, because avrdude now read the unused bits as 1, which gives 0XFD instead of 0X05. The related commit in avrdude is described here : http://svn.savannah.nongnu.org/viewvc?view=rev&root=avrdude&revision=1335

The problem can be fixed by changing the uno.bootloader.extended_fuses value to 0xFD in boards.txt, or by reverting the avrdude.conf to its previous behaviour of ignoring the unused bits. I am not sure which one is better.
In both cases, other boards/uc models might need to be fixed as well.

Version tested: 1.6.10 Hourly Build 2016/07/26 03:25

log.txt

@matthijskooijman

This comment has been minimized.

Show comment
Hide comment
@matthijskooijman

matthijskooijman Jul 29, 2016

Collaborator

IIRC there is a avrude bug report about his. I ran into this as well using a JTAGICE3 ISP programmer. The problem, I think, is that some programmers return 1 for unused bits, and some return 0. This makes it impossible to fix in Arduino, but it was also tricky to fix in avrdude (the info about what pins are unused was not explicitly available in the right places IIRC).

The bug report is here: https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5:-Library-specification#libraryproperties-file-format

That suggests the bug is already fixed a while ago, or perhaps only a part of the problem. It seems you're already using the latest Arduino IDE version, which includes the latest avrdude 6.3 as well.

What programmer are you using?

Collaborator

matthijskooijman commented Jul 29, 2016

IIRC there is a avrude bug report about his. I ran into this as well using a JTAGICE3 ISP programmer. The problem, I think, is that some programmers return 1 for unused bits, and some return 0. This makes it impossible to fix in Arduino, but it was also tricky to fix in avrdude (the info about what pins are unused was not explicitly available in the right places IIRC).

The bug report is here: https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5:-Library-specification#libraryproperties-file-format

That suggests the bug is already fixed a while ago, or perhaps only a part of the problem. It seems you're already using the latest Arduino IDE version, which includes the latest avrdude 6.3 as well.

What programmer are you using?

@matthijskooijman

This comment has been minimized.

Show comment
Hide comment
@matthijskooijman

matthijskooijman Jul 29, 2016

Collaborator

Looking at the avrdude commit, it might be that all programmers are now unified in how they handle things, but perhaps it uses 1s instead of 0s for unused bits on all programmers now? If so, than this indeed needs to be fixed in boards.txt.

Collaborator

matthijskooijman commented Jul 29, 2016

Looking at the avrdude commit, it might be that all programmers are now unified in how they handle things, but perhaps it uses 1s instead of 0s for unused bits on all programmers now? If so, than this indeed needs to be fixed in boards.txt.

@descampsa

This comment has been minimized.

Show comment
Hide comment
@descampsa

descampsa Jul 29, 2016

Contributor

Yes, apparently they have decided that unused bits would not be ignored (replaced by 0s) anymore, but use their actual value of 1 (unprogrammed). It makes more sense like that in my opinion.

Are you sure about the difference between programmers? It seems strange that a programmer would return 0s for unused bits, since the micro will, i think, always return 1s. This would mean that some programmers modify the values and replace the unused by 0 internally...
Anyway, i only have a usbasp to test, so if you have other programmer model, it would probably be good to test to be sure.

Contributor

descampsa commented Jul 29, 2016

Yes, apparently they have decided that unused bits would not be ignored (replaced by 0s) anymore, but use their actual value of 1 (unprogrammed). It makes more sense like that in my opinion.

Are you sure about the difference between programmers? It seems strange that a programmer would return 0s for unused bits, since the micro will, i think, always return 1s. This would mean that some programmers modify the values and replace the unused by 0 internally...
Anyway, i only have a usbasp to test, so if you have other programmer model, it would probably be good to test to be sure.

@per1234

This comment has been minimized.

Show comment
Hide comment
@per1234

per1234 Jul 30, 2016

Collaborator

I can confirm that the same issue occurs with USBtinyISP and Arduino as ISP burning bootloader to Arduino AVR Boards 1.6.12's Uno and other ATmega328P boards . After changing the extended_fuses value to 0xFD the issue is resolved.

I encountered a different, possibly unrelated, issue attempting to Burn Bootloader to any board with Atmel AVRISP mkII:

C:\Program Files (x86)\arduino-1.6.10\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\arduino-1.6.10\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -cstk500v2 -Pusb -e -Ulock:w:0x3F:m -Uefuse:w:0x05:m -Uhfuse:w:0xDE:m -Ulfuse:w:0xFF:m 

avrdude: Version 6.3, compiled on Jun 22 2016 at 16:05:21
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Program Files (x86)\arduino-1.6.10\hardware\tools\avr/etc/avrdude.conf"

         Using Port                    : usb
         Using Programmer              : stk500v2
avrdude: usbdev_open(): Found AVRISP mkII, serno: 000200217496
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : STK500V2
         Description     : Atmel STK500 Version 2.x firmware
         Programmer Model: AVRISP mkII
         Hardware Version: 1
         Firmware Version Master : 1.23
         Vtarget         : 5.3 V
         SCK period      : 8.00 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: erasing chip
avrdude: reading input file "0x3F"
avrdude: writing lock (1 bytes):

Error while burning bootloader.
Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x3F:
avrdude: load data lock data from input file 0x3F:
avrdude: input file 0x3F contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xff != 0x3f
avrdude: verification error; content mismatch

avrdude done.  Thank you.

Atmel AVRISP mkII works as expected with Arduino AVR Boards 1.6.11.

Collaborator

per1234 commented Jul 30, 2016

I can confirm that the same issue occurs with USBtinyISP and Arduino as ISP burning bootloader to Arduino AVR Boards 1.6.12's Uno and other ATmega328P boards . After changing the extended_fuses value to 0xFD the issue is resolved.

I encountered a different, possibly unrelated, issue attempting to Burn Bootloader to any board with Atmel AVRISP mkII:

C:\Program Files (x86)\arduino-1.6.10\hardware\tools\avr/bin/avrdude -CC:\Program Files (x86)\arduino-1.6.10\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -cstk500v2 -Pusb -e -Ulock:w:0x3F:m -Uefuse:w:0x05:m -Uhfuse:w:0xDE:m -Ulfuse:w:0xFF:m 

avrdude: Version 6.3, compiled on Jun 22 2016 at 16:05:21
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\Program Files (x86)\arduino-1.6.10\hardware\tools\avr/etc/avrdude.conf"

         Using Port                    : usb
         Using Programmer              : stk500v2
avrdude: usbdev_open(): Found AVRISP mkII, serno: 000200217496
         AVR Part                      : ATmega328P
         Chip Erase delay              : 9000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page                       Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
           eeprom        65    20     4    0 no       1024    4      0  3600  3600 0xff 0xff
           flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
           lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
           calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

         Programmer Type : STK500V2
         Description     : Atmel STK500 Version 2.x firmware
         Programmer Model: AVRISP mkII
         Hardware Version: 1
         Firmware Version Master : 1.23
         Vtarget         : 5.3 V
         SCK period      : 8.00 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e950f (probably m328p)
avrdude: erasing chip
avrdude: reading input file "0x3F"
avrdude: writing lock (1 bytes):

Error while burning bootloader.
Writing | ################################################## | 100% 0.01s

avrdude: 1 bytes of lock written
avrdude: verifying lock memory against 0x3F:
avrdude: load data lock data from input file 0x3F:
avrdude: input file 0x3F contains 1 bytes
avrdude: reading on-chip lock data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xff != 0x3f
avrdude: verification error; content mismatch

avrdude done.  Thank you.

Atmel AVRISP mkII works as expected with Arduino AVR Boards 1.6.11.

@descampsa

This comment has been minimized.

Show comment
Hide comment
@descampsa

descampsa Jul 30, 2016

Contributor

@per1234 This issue with AVRISP mkII looks more like a avrdude bug, probably related to the programmer specific problem @matthijskooijman was talking about.

One possible fix/workaround would be that avrdude apply the same change on the lock fuse byte than on the extended fuse byte. It would also be more consistent imho.
If you want to try it, you can change the unlock_bits value to 0xFF and lock_bits to 0xCF in boards.txt, and the line 8668 of avrdude.conf (read instruction of lock for atmega328) to :
"x x x x x x x x o o o o o o o o";
This works with the usbasp, and, given your log, i think it should also work with mkII, even if i do not really understand the root cause of the problem.
This is more a discussion to have with avrdude guys, though.

Contributor

descampsa commented Jul 30, 2016

@per1234 This issue with AVRISP mkII looks more like a avrdude bug, probably related to the programmer specific problem @matthijskooijman was talking about.

One possible fix/workaround would be that avrdude apply the same change on the lock fuse byte than on the extended fuse byte. It would also be more consistent imho.
If you want to try it, you can change the unlock_bits value to 0xFF and lock_bits to 0xCF in boards.txt, and the line 8668 of avrdude.conf (read instruction of lock for atmega328) to :
"x x x x x x x x o o o o o o o o";
This works with the usbasp, and, given your log, i think it should also work with mkII, even if i do not really understand the root cause of the problem.
This is more a discussion to have with avrdude guys, though.

@per1234

This comment has been minimized.

Show comment
Hide comment
@per1234

per1234 Jul 31, 2016

Collaborator

After changing the lock_bits and unlock_bits values in boards.txt the same extended fuse issue occurs with Atmel AVRISP mkII and is solved by changing the extended_fuses value to 0xFD.

I'm happy to look into the AVRISP mkII lock and unlock bits issue more on request but from what descampsa said it sounds like it's off topic for this issue report.

Collaborator

per1234 commented Jul 31, 2016

After changing the lock_bits and unlock_bits values in boards.txt the same extended fuse issue occurs with Atmel AVRISP mkII and is solved by changing the extended_fuses value to 0xFD.

I'm happy to look into the AVRISP mkII lock and unlock bits issue more on request but from what descampsa said it sounds like it's off topic for this issue report.

@descampsa

This comment has been minimized.

Show comment
Hide comment
@descampsa

descampsa Jul 31, 2016

Contributor

Good to know it works

The problem is, there is no way to fix it for all programmers in arduino only, avrdude.conf has to be changed. Making the change to the (un)lock_bits only would fix it for mkII, but break (at least) usbasp, USBtinyISP and ArduinoISP compatibility.

A patch has already been proposed for avrdude: see http://savannah.nongnu.org/bugs/?46759 and https://savannah.nongnu.org/patch/index.php?8996 .

Contributor

descampsa commented Jul 31, 2016

Good to know it works

The problem is, there is no way to fix it for all programmers in arduino only, avrdude.conf has to be changed. Making the change to the (un)lock_bits only would fix it for mkII, but break (at least) usbasp, USBtinyISP and ArduinoISP compatibility.

A patch has already been proposed for avrdude: see http://savannah.nongnu.org/bugs/?46759 and https://savannah.nongnu.org/patch/index.php?8996 .

@per1234

This comment has been minimized.

Show comment
Hide comment
@per1234

per1234 Aug 1, 2016

Collaborator

A patch has already been proposed for avrdude: see http://savannah.nongnu.org/bugs/?46759 and https://savannah.nongnu.org/patch/index.php?8996 .

I've successfully tested that patch and reported the issue and my results at arduino/avrdude-build-script#2.

Collaborator

per1234 commented Aug 1, 2016

A patch has already been proposed for avrdude: see http://savannah.nongnu.org/bugs/?46759 and https://savannah.nongnu.org/patch/index.php?8996 .

I've successfully tested that patch and reported the issue and my results at arduino/avrdude-build-script#2.

@matthijskooijman

This comment has been minimized.

Show comment
Hide comment
@matthijskooijman

matthijskooijman Aug 2, 2016

Collaborator

I just compared the avrdude versions hipped with 1.6.9 and 1.6.10 with the STK500 and JTAGICE3 programmers I have lying around. As I remembered, they return different values for the unused bits (note the differences in the high fuse).

matthijs@grubby:~/arduino-1.6.9$ ./hardware/tools/avr/bin/avrdude -C ./hardware/tools/avr/etc/avrdude.conf -h 2>&1 |grep version
avrdude version 6.0.1, URL: <http://savannah.nongnu.org/projects/avrdude/>
matthijs@grubby:~/arduino-1.6.9$ ./hardware/tools/avr/bin/avrdude -C ./hardware/tools/avr/etc/avrdude.conf -c stk500v2 -p m328p -P /dev/ttyUSB0

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.09s

avrdude: Device signature = 0x1e950f

avrdude: safemode: Fuses OK (H:05, E:DE, L:FF)

avrdude done.  Thank you.

matthijs@grubby:~/arduino-1.6.9$ ./hardware/tools/avr/bin/avrdude -C ./hardware/tools/avr/etc/avrdude.conf -c jtag3isp -p m328p

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.20s

avrdude: Device signature = 0x1e950f

avrdude: safemode: Fuses OK (H:FD, E:DE, L:FF)

avrdude done.  Thank you.

However, with avrdude 6.3, both programmers return "1" for unused bits:

matthijs@grubby:~/arduino-1.6.10$ ./hardware/tools/avr/bin/avrdude -C ./hardware/tools/avr/etc/avrdude.conf -h 2>&1 |grep version
avrdude version 6.3, URL: <http://savannah.nongnu.org/projects/avrdude/>
matthijs@grubby:~/arduino-1.6.10$ ./hardware/tools/avr/bin/avrdude -C ./hardware/tools/avr/etc/avrdude.conf -c stk500v2 -p m328p -P /dev/ttyUSB0

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.09s

avrdude: Device signature = 0x1e950f (probably m328p)

avrdude: safemode: Fuses OK (E:FD, H:DE, L:FF)

avrdude done.  Thank you.

matthijs@grubby:~/arduino-1.6.10$ ./hardware/tools/avr/bin/avrdude -C ./hardware/tools/avr/etc/avrdude.conf -c jtag3isp -p m328p

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.19s

avrdude: Device signature = 0x1e950f (probably m328p)

avrdude: safemode: Fuses OK (E:FD, H:DE, L:FF)

avrdude done.  Thank you.

This suggests that indeed the unused bits are now consistent among multiple programmers (though testing on more programmers would be good), however they are inverted as to what boards.txt now lists. I'm mostly confirming what is already stated, though.

This bugreport suggests that there might still be a problem (introduced in 6.2) with the lock bits. I'm not sure if this is already fixed in 6.3, and I didn't dig in the code to see. Testing is probably a good idea (if burn bootloader works, then I think it's ok).

Collaborator

matthijskooijman commented Aug 2, 2016

I just compared the avrdude versions hipped with 1.6.9 and 1.6.10 with the STK500 and JTAGICE3 programmers I have lying around. As I remembered, they return different values for the unused bits (note the differences in the high fuse).

matthijs@grubby:~/arduino-1.6.9$ ./hardware/tools/avr/bin/avrdude -C ./hardware/tools/avr/etc/avrdude.conf -h 2>&1 |grep version
avrdude version 6.0.1, URL: <http://savannah.nongnu.org/projects/avrdude/>
matthijs@grubby:~/arduino-1.6.9$ ./hardware/tools/avr/bin/avrdude -C ./hardware/tools/avr/etc/avrdude.conf -c stk500v2 -p m328p -P /dev/ttyUSB0

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.09s

avrdude: Device signature = 0x1e950f

avrdude: safemode: Fuses OK (H:05, E:DE, L:FF)

avrdude done.  Thank you.

matthijs@grubby:~/arduino-1.6.9$ ./hardware/tools/avr/bin/avrdude -C ./hardware/tools/avr/etc/avrdude.conf -c jtag3isp -p m328p

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.20s

avrdude: Device signature = 0x1e950f

avrdude: safemode: Fuses OK (H:FD, E:DE, L:FF)

avrdude done.  Thank you.

However, with avrdude 6.3, both programmers return "1" for unused bits:

matthijs@grubby:~/arduino-1.6.10$ ./hardware/tools/avr/bin/avrdude -C ./hardware/tools/avr/etc/avrdude.conf -h 2>&1 |grep version
avrdude version 6.3, URL: <http://savannah.nongnu.org/projects/avrdude/>
matthijs@grubby:~/arduino-1.6.10$ ./hardware/tools/avr/bin/avrdude -C ./hardware/tools/avr/etc/avrdude.conf -c stk500v2 -p m328p -P /dev/ttyUSB0

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.09s

avrdude: Device signature = 0x1e950f (probably m328p)

avrdude: safemode: Fuses OK (E:FD, H:DE, L:FF)

avrdude done.  Thank you.

matthijs@grubby:~/arduino-1.6.10$ ./hardware/tools/avr/bin/avrdude -C ./hardware/tools/avr/etc/avrdude.conf -c jtag3isp -p m328p

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.19s

avrdude: Device signature = 0x1e950f (probably m328p)

avrdude: safemode: Fuses OK (E:FD, H:DE, L:FF)

avrdude done.  Thank you.

This suggests that indeed the unused bits are now consistent among multiple programmers (though testing on more programmers would be good), however they are inverted as to what boards.txt now lists. I'm mostly confirming what is already stated, though.

This bugreport suggests that there might still be a problem (introduced in 6.2) with the lock bits. I'm not sure if this is already fixed in 6.3, and I didn't dig in the code to see. Testing is probably a good idea (if burn bootloader works, then I think it's ok).

@descampsa

This comment has been minimized.

Show comment
Hide comment
@descampsa

descampsa Aug 2, 2016

Contributor

This bugreport suggests that there might still be a problem (introduced in 6.2) with the lock bits. I'm not sure if this is already fixed in 6.3, and I didn't dig in the code to see. Testing is probably a good idea (if burn bootloader works, then I think it's ok).

Yes, apparently this issue has not yet been fixed (but a patch has been proposed), @per1234 has run into this problem when testing with AVRISP mkII programmer. He describes the issue and the solution we have found at arduino/avrdude-build-script#2.

Contributor

descampsa commented Aug 2, 2016

This bugreport suggests that there might still be a problem (introduced in 6.2) with the lock bits. I'm not sure if this is already fixed in 6.3, and I didn't dig in the code to see. Testing is probably a good idea (if burn bootloader works, then I think it's ok).

Yes, apparently this issue has not yet been fixed (but a patch has been proposed), @per1234 has run into this problem when testing with AVRISP mkII programmer. He describes the issue and the solution we have found at arduino/avrdude-build-script#2.

@Swiftnesses

This comment has been minimized.

Show comment
Hide comment
@Swiftnesses

Swiftnesses Aug 3, 2016

Updated a few days ago and tonight just spent 6 hours trying to figure out why I could no longer burn bootloaders. Seems this was the issue :(

Swiftnesses commented Aug 3, 2016

Updated a few days ago and tonight just spent 6 hours trying to figure out why I could no longer burn bootloaders. Seems this was the issue :(

@Frederic98

This comment has been minimized.

Show comment
Hide comment
@Frederic98

Frederic98 Aug 17, 2016

I couldn't burn a bootloader anymore, so I updated the arduino ide from 1.6.9 to 1.6.10 and the issue was still there.
I changed line 8657 in avrdude.conf to "x x x x x x x x x x x x x o o o"; and burning the bootloader now works again.

(memory efuse of ATmega328 section)

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 x x x x x 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";
    ;

Edit: "x" means the bit is ignored: [http://www.nongnu.org/avrdude/user-manual/avrdude_13.html#Instruction-Format]

Frederic98 commented Aug 17, 2016

I couldn't burn a bootloader anymore, so I updated the arduino ide from 1.6.9 to 1.6.10 and the issue was still there.
I changed line 8657 in avrdude.conf to "x x x x x x x x x x x x x o o o"; and burning the bootloader now works again.

(memory efuse of ATmega328 section)

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 x x x x x 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";
    ;

Edit: "x" means the bit is ignored: [http://www.nongnu.org/avrdude/user-manual/avrdude_13.html#Instruction-Format]

@cmaglie

This comment has been minimized.

Show comment
Hide comment
@cmaglie

cmaglie Sep 22, 2016

Member

Fixed with #5374

Member

cmaglie commented Sep 22, 2016

Fixed with #5374

@cmaglie cmaglie closed this Sep 22, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment