strange fuse/lockbits

system · June 27, 2018, 2:05pm

hello,
recently I discovered a function that reads and "prints" the fuse/lockbits

#include <avr/boot.h>;

void setup()
{
    Serial.begin(115200);

    cli();
    uint8_t lowBits      = boot_lock_fuse_bits_get(GET_LOW_FUSE_BITS);
    uint8_t highBits     = boot_lock_fuse_bits_get(GET_HIGH_FUSE_BITS);
    uint8_t extendedBits = boot_lock_fuse_bits_get(GET_EXTENDED_FUSE_BITS);
    uint8_t lockBits     = boot_lock_fuse_bits_get(GET_LOCK_BITS);
    sei();

    Serial.print("Low:  0x");
    Serial.println(lowBits, HEX);
    Serial.print("High: 0x");
    Serial.println(highBits, HEX);
    Serial.print("Ext:  0x");
    Serial.println(extendedBits, HEX);
    Serial.print("Lock: 0x");
    Serial.println(lockBits, HEX);
}

void loop() 
{
}

in the boards.txt the values are

unlock : 0X3F

low:0xFF
lock:0x0F
Hi:0xD8
Ex:0xFD

Now, I uploaded the sketch as it is on a mega2560 and get:

Low: 0xFF
High: 0xD8
Ext: 0xFD
Lock: 0xFF

Any idea why the lock is different?

pert · June 27, 2018, 2:41pm

Have you done a Tools > Burn Bootloader on your Mega 2560 so you're certain the fuses are actually set to the values in boards.txt?

When I run the sketch I get this:
Low: 0xFF
High: 0xD8
Ext: 0xFD
Lock: 0xCF

So you'll note that the lock bits still don't match but if you check what the difference is:
boards.txt:

sketch output:

you can see the only difference is the unused bit 6 and 7.

There is some weirdness in how these unused fuse bits are handled. The AVRDUDE tool used by the Arduino IDE to set the fuses used to handle them one way, then changed in v6.3 to handling them the other way because supposedly that is more correct. This caused a lot of breakage so Arduino modified their version of AVRDUDE to still be compatible with the old fuse values. So I believe this causes AVRDUDE to actually write 0xCF even though the board definition says 0x0F.

More info:

github.com/arduino/avrdude-build-script

lock/unlock bits fail to verify with Atmel AVRISP mkII and avrdude 6.3.0-arduino2

opened 01:53AM - 01 Aug 16 UTC

per1234

Using Arduino IDE 1.6.10/Arduino AVR Boards 1.6.12 with Windows 7 64 and 32 bit …1. Tools > Board > Uno 2. Tools > Programmer > AVRISP mkII 3. Tools > Burn Bootloader fails with: ``` Arduino: 1.6.10 (Windows 7), Board: "Arduino/Genuino Uno" 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.4 V SCK period : 8.00 us avrdude: AVR device initialized and ready to accept instructions Reading | ################################################## | 100% -0.00s 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. ``` 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 Arduino AVR Boards 1.6.12's avrdude.conf(attached: [avrdude.conf.txt](https://github.com/arduino/avrdude-build-script/files/392783/avrdude.conf.txt)) and modified the `unlock_bits` and `lock_bits` in boards.txt(attached:[boards.txt](https://github.com/arduino/avrdude-build-script/files/395092/boards.txt))(EDIT: boards.txt updated with a couple edits I missed), which has `extended_fuses` values also modified according to https://github.com/arduino/Arduino/pull/5182. I did **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 the `lock_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 packages that use the affected MCUs and Arduino's avrdude.conf. In order to fix this and maintain backwards compatibility with previous Arduino AVR Boards versions they will need to specify their own avrdude tool(EDIT: I had assumed this patch required a recent AVRDUDE version but this may not be the case?) in the JSON file(EDIT: as well as include it with manual installation files) and include their own avrdude.conf file. Some of these packages will already need to do this due to https://github.com/arduino/Arduino/issues/5175.

system · June 27, 2018, 4:22pm

this doesnt happen here.

I canged lockbits to 0x03, the sketch IS locked and still get 0xFF

system · June 27, 2018, 5:35pm

hmmm it seems there is a problem somewhere

from beginning
I want to lock my application section. For this, I change boards.txt (mega main section) lockbits to 0x0C. Then upload a blink sketch using programmer "arduino as isp" upload ends ok.

Disconnent programmer, connect target mega to usb and try to "simple" upload a sketch. The procedure stops with "connection timeout" (from this i "understood" it is not possible to program, so conclude lockbits ok). (after that I found the function that reads lockbits and tried it and see that there is something wrong)

restore value in boards.txt, Reconnect programmer, burn bootloader go back and verify that now target can get sketch through "upload"

Qs:
is 0x0C correct in order to get "further programming and verification disabled"?
Is procedure correct (change boards.txt, upload using pogrammer (arduino as isp))?

thank you

pert · June 27, 2018, 8:51pm

demkat1:
Is procedure correct (change boards.txt, upload using pogrammer (arduino as isp))?

No, the procedure is not correct. Only Tools > Burn Bootloader sets the fuses. Upload Using Programmer does not set fuses.

You also need to restart the Arduino IDE after changing boards.txt.

You also need to be sure you are editing the right boards.txt. You may have multiple copies on your computer. Turn on File > Preferences > Show verbose output during: > upload and check the output of the Burn Bootloader command to be sure the correct fuse settings were used.

olf2012 · June 27, 2018, 9:30pm

demkat1:
Then upload a blink sketch using programmer "arduino as isp" upload ends ok.

Disconnent programmer, connect target mega to usb and try to "simple" upload a sketch. The procedure stops with "connection timeout" (from this i "understood" it is not possible to program, so conclude lockbits ok)

The conclusion is not correct. "Upload using programmer" deletes the bootloader. So any subsequent attempt with a USB connection will fail, regardless of the fuse settings

system · June 28, 2018, 4:46am

Thank you both

system · June 29, 2018, 3:32pm

it is driving me crazy.

use 1.8.1
Take a mega2560 board. Have an uno "as isp". Burn bootloader. ok, led blinks.
disconnect programmer go to ide,
upload sketch to read fuse and lockbits (see above). ok it works. it gives me E=FD, H=D8, L=FF, lock=CF, as it is on boards.txt (CF=0F unused bits 6,7).

connect "as isp", go to dos window and type

...\avrdude -P COM3 -b 19200 -C ...\avrdude.conf -c arduino -p m2560 -Ulock:w:0x0C:m

ok, writen, verified
disconnect programmer go to ide, sketch ok, it gives me lock=CC.

upload sketch
Sure, why not , "done uploading" and new sketch is "on board"

system · June 30, 2018, 5:33am

demkat1:
it is driving me crazy.

use 1.8.1
Take a mega2560 board. Have an uno "as isp". Burn bootloader. ok, led blinks.
disconnect programmer go to ide,
upload sketch to read fuse and lockbits (see above). ok it works. it gives me E=FD, H=D8, L=FF, lock=CF, as it is on boards.txt (CF=0F unused bits 6,7).

connect "as isp", go to dos window and type

...\avrdude -P COM3 -b 19200 -C ...\avrdude.conf -c arduino -p m2560 -Ulock:w:0x0C:m

ok, writen, verified
disconnect programmer go to ide, sketch ok, it gives me lock=CC.

upload sketch
Sure, why not , "done uploading" and new sketch is "on board"

nobody can say why
"further programming and verification disabled" is not working?
why the chip is not "locked"???

westfw · June 30, 2018, 9:51am

0C should mean serial and parallel programming are disabled (but erase will still work, and erases the lock bits as well.) (0bxxxxxx00) and application section access to the bootloader area is disabled (0bxx00xxxx).
But the bootloader can still access the application section (0bxxxx11xx), which is what you’re seeing, right?

The docs are laid out rather horribly!

(Bootloader programingm isn’t either serial programming or parallel programming as they are using the terms. It’s the bootloader deciding to do self programming. It’s actually a pretty useful state to be in, if you bootloader control secure access to some important stuff...)

system · June 30, 2018, 10:18am

westfw:
0C should mean serial and parallel programming are disabled (but erase will still work, and erases the lock bits as well.) (0bxxxxxx00) and application section access to the bootloader area is disabled (0bxx00xxxx).
But the bootloader can still access the application section (0bxxxx11xx), which is what you’re seeing, right?

So, you mean instead of 0C, use 00?

(I can try it on monday, but since it is "scrubing me", pls be so kind and answer with a Y or N
thank you

westfw · June 30, 2018, 8:03pm

So, you mean instead of 0C, use 00?

To "lock" an arduino, I'd leave the bootloader unprogrammed, and set the Lock bits to 0 (the contents of the boot lock bits would be irrelevant at that point.)
The sequence would look like (using a programmer connected to the ISP port):

"Burn Bootloader" - to set fuses appropriately for the "board."
"Upload using programmer" (erases bootloader, uploads sketch, leaves fuses.) (Hmm. There's some chance that newer IDEs will upload the "sketch and the bootloader combined" image. Keep an eye on it...)
Change lock bits to 0 using avrdude.

system · July 1, 2018, 6:09am

thank you
over and out

system · May 5, 2021, 11:15pm