I have a custom ATMEGA328-MMH board, and I'm flashing it using an Atmel-ICE programmer.
I'm running Arduino 1.8.16, and have the Minicore boards project pulled into my IDE to flash the ATMEGA328.
I can flash applications just fine, but fail to flash the bootloader.
I don't even actually want the Arduino bootloader, I just want to use the "Burn Bootloader" function to program the fuses I need (specifically removing the default clock divider).
Yes, I know that I can do this on the command line using avrdude. This project is for a colleague who will NOT be comfortable using avrdude on the command line.
Anyway here's what I get when I Burn Bootloader:
Arduino: 1.8.16 (Windows Store 1.8.51.0) (Windows 10), Board: "ATmega328, No bootloader, EEPROM not retained, 328 / 328A, BOD 2.7V, LTO disabled, Internal 8 MHz"
C:\Users\ME\Documents\ArduinoData\packages\arduino\tools\avrdude\6.3.0-arduino18/bin/avrdude -CC:\Users\ME\Documents\ArduinoData\packages\MiniCore\hardware\avr\2.1.3/avrdude.conf -v -patmega328 -catmelice_isp -Pusb -e -Ulock:w:0x3f:m -Uefuse:w:0b11111101:m -Uhfuse:w:0b11011111:m -Ulfuse:w:0xe2:m
avrdude: Version 6.3-20201216
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/ Copyright (c) 2007-2014 Joerg Wunsch System wide configuration file is "C:\Users\ME\Documents\ArduinoData\packages\MiniCore\hardware\avr\2.1.3/avrdude.conf" Using Port : usb Using Programmer : atmelice_ispavrdude: Found CMSIS-DAP compliant device, using EDBG protocol
AVR Part : ATmega328 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 : JTAG3_ISP Description : Atmel-ICE (ARM/AVR) in ISP mode Vtarget : 4.9 V SCK period : 8.00 usavrdude: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.00s
avrdude: Device signature = 0x1e9514 (probably m328)
avrdude: erasing chip
avrdude: reading input file "0x3f"
avrdude: writing lock (1 bytes):
Writing | ################################################## | 100% 0.00s
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: WARNING: invalid value for unused bits in fuse "lock", should be set to 1 according to datasheet
This behaviour is deprecated and will result in an error in future version
You probably want to use 0xff instead of 0x3f (double check with your datasheet first).
avrdude: 1 bytes of lock verified
avrdude: reading input file "0b11111101"
avrdude: writing efuse (1 bytes):
Error while burning bootloader.
Writing | ################################################## | 100% 0.09s
avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0b11111101:
avrdude: load data efuse data from input file 0b11111101:
avrdude: input file 0b11111101 contains 1 bytes
avrdude: reading on-chip efuse data:
Reading | ################################################## | 100% 0.00s
avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
0xff != 0xfdavrdude: verification error; content mismatch
avrdude done. Thank you.
I did a lot of searching around and found a few breadcrumbs. It looks like it may have been addressed back in 1.6.12 but I'm still seeing the issue above and unsure of next steps. I can brute force the fuses in Microchip Studio but this again will not be acceptable for the end user.