Arduino Mega2560 bootloader and programming

Can I pick a few brains regarding the Arduino Bootloader on Mega2560.

My understanding is that the bootloader code for mega2560 is in stk500boot.c

Reading stk500boot.c it says that to initiate the bootloader, PROG-PIN has to be pulled low.

I'm having trouble finding where PROG_PIN is actually defined.

I had assumed it was a port pin which the ATmega16 USB interface would pull low when the USB cable was connected?

On the Mega2560 schematic I couldn't see a PROG_PIN anywhere.

I did find some defines for it as bit 0 on the PROG_PORT?

Can anyone enlighten me as to exactly how the bootloader is initiated on a Mega2560 Arduino?

I want to know because I have the bootloader in a 'breadboard' Arduino which successfully loaded my application once but now there's application code in there, it won't connect to re-load.

I am guessing that the bootloader is starting the application immediately due to PROG_PIN not being low?

Any help greatly appreciated.

Just looking some more at stk500boot.c, maybe PROG_PIN is a red herring and it just looks for some incoming data before the timeout expires (1 second) it runs the application code.

richardtheboffin:
Can anyone enlighten me as to exactly how the bootloader is initiated on a Mega2560 Arduino?

I want to know because I have the bootloader in a 'breadboard' Arduino which successfully loaded my application once but now there's application code in there, it won't connect to re-load.

Use a diode, resistor and two capacitors on the reset line like this:

Connect the DTR of your USB-Serial to 100N capacitor.
Connect RXD/TXD of your USB-Serial adapter to the UART0 of the ATMega.

Connect your ISP Programmer to the board and set the correct fuses.
Pay attention to the "Boot-Flash-Size", correct clock and disable JTAG and set the correct clock divider.

Burn the bootloder bootloader using the ISP programmer, it should be "stk500boot_v2_mega2560.hex" found in the arduino directory under hardware.

Now it should work.
The bootloader is initialised at startup, there is not extra pin. DTR is pulsed wich resets the AVR and executes the bootloader wich then waits for data on the TX/RD pins.
If no data is received the bootloader jumps to the main program.

Ahh ok, thanks.

I figured out the references to PROG_PIN being held low were obsolete now.

My usb interface doesn't have a DTR only RTS/CTS control signals!

My understanding of the bootloader is that it only waits for a second after reset for comms from AVRDUDE. Hence the need for a reset controlled by the PC running AVRDUDE.

How easy is it to rebuild the bootloader in AVR Studio, for example, and to increase that timeout so I can manually force a reset with a button?

I've tried putting the .c and .h files into a project and it builds, but it's not picking up all the device specific stuff that's in the bootloader makefile...

You don't use AVR Studio to build the stk500v2 bootloader. For PC platform the easiest is to install WinAVR-20100110 and run make in the stk500v2 folder.

PeterFW:
Use a diode, resistor and two capacitors on the reset line like this:
http://www.gammon.com.au/images/Arduino/Arduino_forum_154906c.png

What's the diode for?

Krupski:
What's the diode for?

See, http://forum.arduino.cc/index.php?topic=310109.msg2151069#msg2151069

Diode keeps the part from going into high voltage (12V) programming mode if the reset switch creates a big pulse, making the uC act like it's hung up.

See attached app note also.

atmel-AVR042-avr-hardware-design-considerations_application-note 7-2013.pdf (758 KB)

You could uh, get a USB serial adapter with the DTR pin broken out, like the classic FTDI adapter?

Or if you're using the cheapo CH340G ones, look up the pinout - you can get on the DTR pin pretty easily and bring a wire out.

hiduino:
You don't use AVR Studio to build the stk500v2 bootloader. For PC platform the easiest is to install WinAVR-20100110 and run make in the stk500v2 folder.

OK, I'll give that a go!

Thanks!

So far I have tried using avr_gcc and Studio but neither are allowing me to build the bootloader.

DrAzzy:
You could uh, get a USB serial adapter with the DTR pin broken out, like the classic FTDI adapter?

Or if you’re using the cheapo CH340G ones, look up the pinout - you can get on the DTR pin pretty easily and bring a wire out.

I have a board to work with (not my design) that has an FTDI FT230x on. No DTR on that chip unfortunately.

I was planning to mod the bootloader to wait around a bit for the programmer commands before running the application.

It’s behaving very oddly at the moment. Sometimes if I reset the board while the Arduino IDE is attempting download, it all synch’s up and works, sometimes it just won’t play dice.

Usually you can press & hold the reset button, release it when the IDE shows "compiled xxx of 128xxx bytes". Can be easier to see it coming with File:Preferences:Verbose Outputs turned on.

You could also try this: bring RTS out and use that as the DTR input.

CrossRoads:
You could also try this: bring RTS out and use that as the DTR input.

Yes I might try that, unfortunately RTS is not tracked anywhere and the USB device is tiny... :roll_eyes:

Using a manual reset, I get inconsistent results.

Depending on what application code is loaded, I can either reliably reset the mega2560 and the download will start as soon as it comes out of reset.

Load a different application and it's impossible to download again unless I flash the bootloader (and therefore erase the application code).

Really weird.

For example a very simple LED flashing sketch seems to prevent the bootloader from being initiated on reset.

I can see avrdude tries to connect every 10 seconds.

If I reset the mega2560, avrdude sends the initial command immediately (doesn't wait 10 seconds). I assume it's detecting a null coming from the mega2560 uart on reset.

But the bootloader isn't seeing it, or it's just going to the application code immediately.

Things are making a little more sense now!

When I reset the mega, it sends out a NULL. Avrdude responds with an init packet. Trouble is, it responds almost exactly at the same time that the bootloader gives up and runs the app code!

Sometimes you can catch it sometimes you can’t.

If I could rebuild the bootloader to hang on another 100ms it would work fine!

I have yet to get the bootloader to build though… :slightly_frowning_face:

Right I got the bootloader to build, but with this difference in the hex files:

:10E1B000652020203D20004D617220323520323014 new
:10E1B000652020203D20004D617220203720323024 old

:10E1C000313500312E362E3700342E332E330056A3 new
:10E1C000313300312E362E3800342E332E350056A2 old

I'm just going to mod the timeout and see if it works!

You can ignore those differences. Those are just the different build dates and library versions in the data fields in the bootloader.

Make sure you are building the correct mcu type.

make mega2560

Looks like the NULL the the mega sends (which forces avrdude to send the init) was actually from the application code starting, so increasing the bootloader timeout didn't help. It just made the NULL take longer to get sent!

So I just send a NULL when the bootloader starts waiting for commands and it now works perfectly.

I can manually reset, the bootloader sends a null, avrdude sends the init and away we go.

Took all day to get to the bottom of this, but at least I know how the bootloader works now...

Time for bed said Zebedee. :sleeping: