Bootloading Custom Mega2560 - Help Needed

I created a reduced version of the MEGA2560 with a built in audio shield and I am having issues bootloading.

I can bootload a “normal” MEGA2560 connected through a Uno via the ISP without any issues.

When I connect my custom board I get errors:

Ardunio as ISP:
avrdude: Yikes! Invalid device signature.
Double check connections and try again.

AVR as ISP:
avrdude: stk500_recv(): Programmer not responding
avrdude: stk500_getsync() attemp 1 of 10: not in sync: resp:0x03

I get the same errors when the boards are powered through USB then ISP, or if I power the board that is being programmed separately.

I think the issue is something very basic that I am missing. Attached is the schematic. Any help is very much appreciated.

Thanks,
Luckykid

luckykid:
I created a reduced version of the MEGA2560 with a built in audio shield and I am having issues bootloading.

I can bootload a "normal" MEGA2560 connected through a Uno via the ISP without any issues.

A quick glance at the schematic seems like everything is all right (at least with regards to the MEGA2560).

Is the processor a "brand new" part (that is, one that's never been programmed before and therefore has the Atmel default fuse settings)?

When you say "having issues bootloading" do you mean you cannot burn a bootloader, or do you mean you successfully DID burn a bootloader, but now you can't use the bootloader to upload newly compiled sketches?

Is the "BOOTRST" bit (high fuse, bit 0) programmed (that is, would read back as 0)? The factory default for that bit is "unprogrammed" (reads as 1) which makes the processor jump to 0x0000 upon reset. If you HAVE a bootloader programmed in, then BOOTRST needs to be programmed (set to 0) so that it jumps to the bootloader upon reset.

AND... the BOOTSZ1 and BOOTSZ0 bits need to be properly set to define the address the bootloader resides in (as well as WHAT address the BOOTRST jumps to - which should be the first byte of the bootloader of course).

That's all I can think of for now.....

Krupski:
Is the processor a "brand new" part (that is, one that's never been programmed before and therefore has the Atmel default fuse settings)?

Yes, brand new part.

Krupski:
When you say "having issues bootloading" do you mean you cannot burn a bootloader, or do you mean you successfully DID burn a bootloader, but now you can't use the bootloader to upload newly compiled sketches?

The bootloader will not load at all. I only receive errors like "Invalid device signature". I can however plug in a regular Arduino MEGA2560 and the same bootloader burns fine.

Krupski:
Is the "BOOTRST" bit (high fuse, bit 0) programmed (that is, would read back as 0)? The factory default for that bit is "unprogrammed" (reads as 1) which makes the processor jump to 0x0000 upon reset. If you HAVE a bootloader programmed in, then BOOTRST needs to be programmed (set to 0) so that it jumps to the bootloader upon reset.

AND... the BOOTSZ1 and BOOTSZ0 bits need to be properly set to define the address the bootloader resides in (as well as WHAT address the BOOTRST jumps to - which should be the first byte of the bootloader of course).

I will look into that. Do you have a resource that explains where these settings are located?

I appreciate the help, thus far. I am in over my head on this one, but I am sure its something basic.

You have two 3.3V devices on the CMISO pin that go unbuffered back to the processor.
One has its CS pin pulled up, one does not, leading to an unknown level the CS pins of the 2560 are inputs when the programmer controls the Reset line during programming,
The problem could be either one dragging the MISO line down via internal clamp diodes and interfering with MISO from the 2560.
I use a buffer with enable such as 74HC125 to only allow MISO from a 3.3V device to drive the line when its CS is active.

CrossRoads:
You have two 3.3V devices on the CMISO pin that go unbuffered back to the processor.
One has its CS pin pulled up, one does not, leading to an unknown level the CS pins of the 2560 are inputs when the programmer controls the Reset line during programming,
The problem could be either one dragging the MISO line down via internal clamp diodes and interfering with MISO from the 2560.
I use a buffer with enable such as 74HC125 to only allow MISO from a 3.3V device to drive the line when its CS is active.

If I disconnect CMISO while bootloading then reconnect there after would that be enough of a work around?

Do you think that is why I am getting the error? Would I have the same issue with CMOSI and CSCK?

Thanks,
LuckyKid

I thought I saw CMOSI & CSCK were buffered to 3.3V levels, so they should not be impacted.
If you had a jumper to disconnect CMISO during bootloading you'd likely solve the problem.

CrossRoads:
I thought I saw CMOSI & CSCK were buffered to 3.3V levels, so they should not be impacted.
If you had a jumper to disconnect CMISO during bootloading you'd likely solve the problem.

I just disconnected it and there is progress!!

avrdude: Expected signature for ATmega2560 is 1E 98 01
Double check chip, or use -F to override this check.
Wrong microcontroller found. Did you select the right board from the Tools > Board menu?

This was using the Arduino as ISP programmer.

Any ideas from here? I feel like we are so close!

Thanks,
Lucky Kid

luckykid:
I just disconnected it and there is progress!!

avrdude: Expected signature for ATmega2560 is 1E 98 01
Double check chip, or use -F to override this check.
Wrong microcontroller found. Did you select the right board from the Tools > Board menu?

This was using the Arduino as ISP programmer.

Any ideas from here? I feel like we are so close!

Thanks,
Lucky Kid

DO NOT have a SDcard inserted when you try to program it. I have a Custom 2560 board and pulled my hair out because the ISP program cycle would fail at different memory addresses based on the bit stream. My SDcard was waking up (with CS_SDcard HIGH), and messing up the MISO data.

What is the value you are receiving as the signature?

What is the voltage on the Reset pin (cpu)?

chuck.

chucktodd:
DO NOT have a SDcard inserted when you try to program it. I have a Custom 2560 board and pulled my hair out because the ISP program cycle would fail at different memory addresses based on the bit stream. My SDcard was waking up (with CS_SDcard HIGH), and messing up the MISO data.

What is the value you are receiving as the signature?

What is the voltage on the Reset pin (cpu)?

chuck.

Here is the full error I am getting now. The previous error was Device signature = 0x00000000

C:\Users\Roy\AppData\Roaming\Arduino15\packages\arduino\tools\avrdude\6.0.1-arduino2/bin/avrdude -CC:\Users\Roy\AppData\Roaming\Arduino15\packages\arduino\tools\avrdude\6.0.1-arduino2/etc/avrdude.conf -v -patmega2560 -cstk500v1 -PCOM3 -b19200 -e -Ulock:w:0x3F:m -Uefuse:w:0xFD:m -Uhfuse:w:0xD8:m -Ulfuse:w:0xFF:m

avrdude: Version 6.0.1, compiled on Mar 19 2015 at 14:43:01
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch

System wide configuration file is "C:\Users\Roy\AppData\Roaming\Arduino15\packages\arduino\tools\avrdude\6.0.1-arduino2/etc/avrdude.conf"

Using Port : COM3
Using Programmer : stk500v1
Overriding Baud Rate : 19200
AVR Part : ATmega2560
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PA0
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 10 8 0 no 4096 8 0 9000 9000 0x00 0x00
flash 65 10 256 0 yes 262144 256 1024 4500 4500 0x00 0x00
lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
lock 0 0 0 0 no 1 0 0 9000 9000 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 : STK500
Description : Atmel STK500 Version 1.x firmware
Hardware Version: 2
Firmware Version: 1.18
Topcard : Unknown
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.05s

avrdude: Device signature = 0xffffff (retrying)

Reading | ################################################## | 100% 0.05s

avrdude: Device signature = 0xffffff (retrying)

Error while burning bootloader.
Reading | ################################################## | 100% 0.05s

avrdude: Device signature = 0xffffff
avrdude: Yikes! Invalid device signature.
Double check connections and try again, or use -F to override
this check.

avrdude done. Thank you.

I am getting 4.89V on the reset pin powered through the ISP, and 5.25V when powered from an external source.

The device signature error keeps changing as well:

Device signature = 0xffff00
Device signature = 0xff0100
Device signature = 0xff0000

Update - I've also added 2 x 22pf caps on XTAL1 and XTAL2 to ground. No change.

luckykid:
I will look into that. Do you have a resource that explains where these settings are located?

Yes sir... 2560 DATASHEET LINK

Start at page 310.

There are different tables for the fuses and bits (ATMega 1280, 640 and 2560)... be sure you are looking at the 2560 tables!

luckykid:
Update - I've also added 2 x 22pf caps on XTAL1 and XTAL2 to ground. No change.

Do you have a good oscilloscope? Try to see if the crystal is oscillating. Use the 10x probe setting. You should see a sine wave centered around VCC/2 and with a P-P amplitude of about 2 to 3 volts (may be much lower due to loading from your scope probe, but if it's there at all, that means the crystal IS oscillating).

Also, check the CLKO (Clock Out) pin (pin 9, PE7) and see if there's a 5V p-p square wave coming out (this assumes that the CKOUT bit (low fuse, bit 6) is programmed (that is, reads back as 0).

Krupski:
Do you have a good oscilloscope? Try to see if the crystal is oscillating. Use the 10x probe setting. You should see a sine wave centered around VCC/2 and with a P-P amplitude of about 2 to 3 volts.

Also, check the CLKO (Clock Out) pin (pin 9, PE7) and see if there's a 5V p-p square wave coming out (this assumes that the CKOUT bit (low fuse, bit 6) is programmed (that is, reads back as 0).

I do not have a scope :frowning: , but I do have an amazon prime membership and credit card.

Would this work? Amazon Scope

Do you see anything with the fuses we are using now that might be wrong?

I did some more testing and it appears that U10 does not seem to be working which is the 1.8V regulator for the VLSI chip.

Although this appears to be an issue, would this prevent the ATMEL from bootloading?

After further inspecting the board the following components were incorrect.

R3,4,5 = 10ohm vs. 10K (Reset, SCL, SDA Pull Up)
R22 = 500K vs. 1M (VLSI chip oscillator circuit)
C32 = 22K resistor verus 22pf cap. (VLSI chip oscillator circuit)

Is it possible that the wrong pull ups fried the chip?

Is this common from board houses? I am amazed at how many things are wrong.

10 ohm pullup on SCL/SDA would do it for the 2560.
Was the board working with C32 = 22K resistor versus 22pf cap like that?

As for errors - the board house I use has me drop ship the parts to them, so the right stuff gets ordered.

CrossRoads:
10 ohm pullup on SCL/SDA would do it for the 2560.
Was the board working with C32 = 22K resistor versus 22pf cap like that?

As for errors - the board house I use has me drop ship the parts to them, so the right stuff gets ordered.

Thanks for the help with this, I really appreciate it. You've and the others on here likely saved us weeks of shooting in the dark!

I post when I get the 2nd set of boards and see if that works.

luckykid:
After further inspecting the board the following components were incorrect.

R3,4,5 = 10ohm vs. 10K (Reset, SCL, SDA Pull Up)
R22 = 500K vs. 1M (VLSI chip oscillator circuit)
C32 = 22K resistor verus 22pf cap. (VLSI chip oscillator circuit)

Is it possible that the wrong pull ups fried the chip?

Is this common from board houses? I am amazed at how many things are wrong.

the 10 ohm on reset would inhibit ISP programming and possibly damage the ISP programmer.

What board fab did you use? I want to know to avoid it!

Chuck.

10 ohm on Reset - I missed that. Not too many programmers could pull that low to get the chip into programming mode;
5V/10ohm = 500mA drive current needed.

Just got the new board. No hardware mods at all and here are the results:

C:\Users\Roy\AppData\Roaming\Arduino15\packages\arduino\tools\avrdude\6.0.1-arduino2/bin/avrdude -CC:\Users\Roy\AppData\Roaming\Arduino15\packages\arduino\tools\avrdude\6.0.1-arduino2/etc/avrdude.conf -v -patmega2560 -cstk500v1 -PCOM3 -b19200 -Uflash:w:C:\Users\Roy\AppData\Roaming\Arduino15\packages\arduino\hardware\avr\1.6.2/bootloaders/stk500v2/stk500boot_v2_mega2560.hex:i -Ulock:w:0x0F:m
Reading | ################################################## | 100% 0.02s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified

avrdude done. Thank you.

avrdude: Version 6.0.1, compiled on Mar 19 2015 at 14:43:01
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch

System wide configuration file is "C:\Users\Roy\AppData\Roaming\Arduino15\packages\arduino\tools\avrdude\6.0.1-arduino2/etc/avrdude.conf"

Using Port : COM3
Using Programmer : stk500v1
Overriding Baud Rate : 19200
AVR Part : ATmega2560
Chip Erase delay : 9000 us
PAGEL : PD7
BS2 : PA0
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 10 8 0 no 4096 8 0 9000 9000 0x00 0x00
flash 65 10 256 0 yes 262144 256 1024 4500 4500 0x00 0x00
lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
lock 0 0 0 0 no 1 0 0 9000 9000 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 : STK500
Description : Atmel STK500 Version 1.x firmware
Hardware Version: 2
Firmware Version: 1.18
Topcard : Unknown
Vtarget : 0.0 V
Varef : 0.0 V
Oscillator : Off
SCK period : 0.1 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.06s

avrdude: Device signature = 0x1e9801
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "C:\Users\Roy\AppData\Roaming\Arduino15\packages\arduino\hardware\avr\1.6.2/bootloaders/stk500v2/stk500boot_v2_mega2560.hex"
avrdude: writing flash (257918 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 257918 bytes of flash written
avrdude: verifying flash memory against C:\Users\Roy\AppData\Roaming\Arduino15\packages\arduino\hardware\avr\1.6.2/bootloaders/stk500v2/stk500boot_v2_mega2560.hex:
avrdude: load data flash data from input file C:\Users\Roy\AppData\Roaming\Arduino15\packages\arduino\hardware\avr\1.6.2/bootloaders/stk500v2/stk500boot_v2_mega2560.hex:
avrdude: input file C:\Users\Roy\AppData\Roaming\Arduino15\packages\arduino\hardware\avr\1.6.2/bootloaders/stk500v2/stk500boot_v2_mega2560.hex contains 257918 bytes
avrdude: reading on-chip flash data:

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

avrdude: verifying ...
avrdude: 257918 bytes of flash verified
avrdude: reading input file "0x0F"
avrdude: writing lock (1 bytes):

Writing | ################################################## | 100% 0.05s

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

Reading | ################################################## | 100% 0.02s

avrdude: verifying ...
avrdude: 1 bytes of lock verified

avrdude done. Thank you.

I think it worked...?

luckykid:
Just got the new board. No hardware mods at all and here are the results:

I think it worked...?

Looks, good! did it wake up?

Chuck.