Hello,
I'm trying to program the bootloader onto a custom PCB which includes an ATMEGA2560 chip. I have an ICSP header (wired per the Arduino ATMEGA2560) on my custom PCB and want to use a genuine Arduino Uno rev3.3 as the ISP.
I have read-through several posts related to this topic and followed wiring and code instructions noted in the tutorial. https://www.arduino.cc/en/Tutorial/ArduinoISP#toc3 however, I'm getting errors when selecting "Burn Bootloader" using the Arduino IDE. The error I'm getting is:
Sketch uses 1460 bytes (0%) of program storage space. Maximum is 253952 bytes.
Global variables use 9 bytes (0%) of dynamic memory, leaving 8183 bytes for local variables. Maximum is 8192 bytes.
C:\Users\XXXX\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino14/bin/avrdude -CC:\Users\XXXX\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino14/etc/avrdude.conf -v -patmega2560 -cwiring -PCOM8 -b115200 -D -Uflash:w:C:\Users\XXXX\AppData\Local\Temp\arduino_build_826830/Blink.ino.hex:i
avrdude: Version 6.3-20171130
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2014 Joerg Wunsch
System wide configuration file is "C:\Users\XXXX\AppData\Local\Arduino15\packages\arduino\tools\avrdude\6.3.0-arduino14/etc/avrdude.conf"
Using Port : COM8
Using Programmer : wiring
Overriding Baud Rate : 115200
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer
avrdude done. Thank you.
An error occurred while uploading the sketch
Once I'm able to burn the bootloader, I would like to be able to upload Arduino code using an FT232RL chip connected to RX0/TX0. I have two other FT232RL chips allowing serial comms to 3 separate PC USB ports. My schematic is attached.
Any feedback or pointing me in the right direction would be greatly appreciate.
Couple things:
Why so few decoupling caps? Each Vcc pin on the Mega needs one, you only used two.
Nice filtering on Avcc at the same time.
The inputs 1,2,4,5 into U5A will likely need pullup resistors to make a proper reset pulse, otherwise they will just go low and not go back high after the DTR signal goes low. That could also be interfering with Reset from the Programmer trying to control the line during Burn Bootloader operation.
U5 should also have a decoupling cap.
Where is RST coming from on U5? I don't see that on the page.
Did the FTDIs on Tx1, Tx2 need to reset the 2560? Normally those would just be serial ports, and only Tx0 would be resetting the chip for a software download. I wouldn't think you'd want resets coming in perhaps randomly from the other serial ports.
CrossRoads,
I really appreciate your time to review and respond to my post! Thank you.
VVC decoupling caps on pins 80, 61, 31 and 10 of the AT2560 are noted on schematic page 1 but yes, your point is well taken. Decoupling on U5 was missed. Thanks for pointing it out.
Wasn't sure if the FTDI's would need to reset the AT2560. I put the decoupling caps there just in case as they can be easily removed. You are correct, since the AT2560 will only send and receive serial commands via USB2 and USB3 (not flashing programs), this connection could be removed - minimizes circuit to a simpler 2 input AND gate layout.
RST on U5 is coming from the DS1388Z RTC output noted on schematic page 1.
From the FTDI232 spec sheet, the DTS output is an active low TTL output. Nothing stating it's an open collector output either therefore I did not think a pull-up would be required. Each DTS output is driving a high impedance AND gate input - again no pullup should be required. That said, you do bring up a good point so I will scope out the Reset input on the AT2560 to make sure it is pulsing correctly.
Again, thank you for responding to my post.
bp
Glad to help.
The Reset Pulse is made by DTR taking one side of the 0.1uF cap low, which then transitions to the other side, and then a 10K pullup resistor pulls it back high after at a 0.1uF/10K ohm time constant rate (as caps only like to pass AC signals effectively (and inductors only like to pass DC)). Since you have a gate between the R (to be added) & C, the 10K at the 2560 Reset pin can't create that reset time constant.
The FTDI needs to cause a Reset to kick off the bootloader so it will look to the PC for a code download.
No Reset, no code download via serial.
"80, 61, 31 and 10" but you only have 2 caps, and 1 more that is isolated via inductor for Avcc. There should have been 4 plus the Avcc cap.
"RST on U5 is coming from the DS1388Z RTC output noted on schematic page 1." Is that something not posted? I don't see that chip.
Follow-up post to my original...
I have found the problem. It was related to the RESET line suggested by CrossRoads but nothing to do with pull-up resistors. It did however lead me to a circuit design mistake I made so thank you!
If you can reference the schematic I posted above, the output of the AND gate is connected to the uC RESET pin. It is also connected to the RESET pin on ICSP port on my board. When using a programmer to flash bootloader (Uno or Atmel-ICE), it requires the output of the programmer to pulse the 2560 reset line low to start the upload. When monitoring the reset pin on the 2560, I saw it pulsed down to only only 2.5V. This is because the output of the programmer (driving low) conflicted with the output of the AND gate (driving high).
Once i resolved this issue (pulled the AND gate chip off the board), the bootloader flashed flawlessly. I was able to upload the famous "blink" program indicating the link through the FT232 works as designed and expected.
Thank you all once again for leading me down the right path! Also, kudos to countless others who have researched and posted on similar subject matter.
