Can't write to lock byte in ATMEGA2560

Hardware
#1

Long story short, I have an arduino mega-based custom board (…that directly copies the Atmega2560 and atmega16u2 configuration as on the Mega board.)

On my new board, I can put code in through ISP (using Arduino-as-ISP), but not through USB. I have flashed the atmega16U2 chip and it is working (and showing up in the IDE as a Mega 2560) However, programming via USB always times out. Using a scope I can see that the first byte from the IDE is getting all the way to the RX pin on the Atmega2560, but nothing is coming back out as a response. The Atmega2560 isn’t doing anything.

I looked at actual ‘good’ arduino mega board and used Nick Gammon’s ‘Atmega_Board_Detector’ sketch. Among the Fuses and bootloader there are only two things that did not match with my custom board

‘good’ Mega board:
Lock byte = 0xFF
Clock calibration = 0x8D

‘bad’ custom board:
Lock byte = 0xCF
Clock calibration = 0x82

From what can tell in the data sheet, the ‘clock calibration’ byte seems unrelated to bootloading.

My next step is to write the lock byte on the bad board to match the 0xFF seen on the good board. When I try to do THAT with avrdude, I keep getting a ‘failed’ message when it actually tries to write to the lock byte.

soo… Anyone have any idea how/why those two variables are causing my board to not be programmable from the IDE?

#2

Does the LED you’ve connected to pin 13 blink when you reset the ATmega2560?

#3

it does not. I don’t have that LED in my design, but that pin is not used, and I probed it with a scope.

#4

Make life easier on yourself and get a Programmer that will let you set the fuses easier.
$7.77, free shipping

Go into boards.txt and set the fuses how you want, then Burn bootloader to get them into the chip.

#5

Thanks. I’ve been able to set the fuses like I want (so they match the ‘good’ mega board, except the the clock config byte) , but the atmega2560 on my boards still doesn’t seem to be running the bootloader.

Any ideas why? I’ve tried everything I’ve read about and can think of.

#6

Were I in your shoes I would use ICSP to upload a simple blinky to ensure the processor is correctly clocked / undamaged then turn my attention to the bootloader.

#7

Already done. I can program it with the ICSP and everything works great.

#8

The usual culprits are: Wrong bootloader or wrong fuses (including the lock-bits).

Meticulously try again to burn the bootloader.

#9

First, I appreciate your help. Thank you. The MD5 sum of the bootloader in the custom board matches the one in the working Arduino Mega. The fuses match as well, except for the clock calibration. The values I get from Gammon’s sketch are as follows:

I’m running out of ideas. I have two of these custom boards that are behaving the same way.

#############
Atmega chip detector.
Written by Nick Gammon.
Version 1.20
Compiled on May 3 2021 at 17:27:55 with Arduino IDE 10812.
Attempting to enter ICSP programming mode …
Entered programming mode OK.
Signature = 0x1E 0x98 0x01
Processor = ATmega2560
Flash memory size = 262144 bytes.
LFuse = 0xFF
HFuse = 0xD8
EFuse = 0xFD
Lock byte = 0xFF
Clock calibration = 0x82
Bootloader in use: Yes
EEPROM preserved through erase: No
Watchdog timer always on: No
Bootloader is 8192 bytes starting at 3E000
…
…
MD5 sum of bootloader = 0xD9 0xE6 0x6B 0x4E 0xD1 0xA6 0x11 0x2C 0x61 0x8F 0x9B 0xD5 0x5D 0x24 0xE2 0x13

#10

I suspect you know but, in case not, it’s worth mentioning: The clock calibration is irrelevant for what you’re doing.

#11

While unlikely it is possible Nick’s program has a bug.

Are you familiar with using avrdude by hand?

#12

The chip is totally unlocked. Are you trying to lock it?

#13

Yes, determined that was the case.

#14

That is the setting I see on the working Arduino Mega board I have. I was just trying to duplicate that since it works like I expect. Should the chip be locked down to run?

#15

It doesn’t need to be locked to run. I have never locked a chip in any of my projects over the last 10+ years.