Unreliable fuses with Atmega328p and Atmel-ICE

1

Hi, I have worked on a project for a few days and this started happening… Is it due to a failed chip?? Is there something I can do software related? My platform.ini config was working great before. On the last upload, my TFT screen on my project started printing white noise D:

[env:ATmega328P]

platform = atmelavr

board = ATmega328P
framework = arduino
upload_protocol = atmelice_isp
upload_flags = -e
upload_port = usb


; do not forget to run burn fuse task if changing values

board_fuses.hfuse = 0xDF    ;smallest flash section size 256 since not using a bootloader with ICE programmer

board_fuses.lfuse = 0xE2    ;int 8MHz crystal (16MHz not working with less than 5V PSU)

board_fuses.efuse = 0xFE    ;BOD at 1.8V, perfect for low power


lib_deps = 

    adafruit/Adafruit ST7735 and ST7789 Library@^1.6.0

    adafruit/Adafruit BusIO@^1.5.0

    adafruit/RTClib@^1.11.3

    ;adafruit/DHT sensor library@^1.4.0

    adafruit/RTClib@^1.12.1

Now the problem when uploading:

RAM:   [====      ]  39.0% (used 799 bytes from 2048 bytes)
Flash: [=====     ]  51.6% (used 16630 bytes from 32256 bytes)
Configuring upload protocol...
AVAILABLE: atmelice_isp
CURRENT: upload_protocol = atmelice_isp
Looking for upload port...
Use manually specified: usb
Uploading .pio\build\ATmega328P\firmware.hex

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 ".pio\build\ATmega328P\firmware.hex"
avrdude: writing flash (16630 bytes):

Writing | ################################################## | 100% 4.77s

avrdude: 16630 bytes of flash written
avrdude: verifying flash memory against .pio\build\ATmega328P\firmware.hex:
avrdude: load data flash data from input file .pio\build\ATmega328P\firmware.hex:
avrdude: input file .pio\build\ATmega328P\firmware.hex contains 16630 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 4.73s

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

avrdude: safemode: Verify error - unable to read lfuse properly. Programmer may not be reliable.
avrdude: safemode: Verify error - unable to read lfuse properly. Programmer may not be reliable.
avrdude: safemode: Sorry, reading back fuses was unreliable. I have given up and exited programming mode

avrdude done.  Thank you.

*** [upload] Error 1
==================================================================== [FAILED] Took 14.03 seconds ====================================================================
2

Mismatch directly on the first byte isn’t good. I see you did put upload_flags = -e which should erase the chip before programming, so that technically shouldn’t occur if the chip is okay. AVRdude also says that erases the chip:

And then it all becomes unstable

Is the TFT connected to power while programming? Does disconnecting the TFT during program improve things?

3

Hi Max, I found the problem as I tried to upload the code to another chip and it too got bricked. I realized it was probably something wrong with the firmware. I believe it was the fact that I had 2 versions of the RTClib in my .ini file… Which seems very weird and scary that a library version can mess around with the fuse settings… Anyway since I removed it I have been able to program this code…
And when the error occured I had a message that the Lfuse was set to 0… I tried reprogramming the chip that was bricked (or seemed like it, even though 0 to Lfuse should prevent from programming) an hour later and it worked. I am very confused, but it seems like making sure I dont have library duplicates in my ini is the solution