ATmega2561 bootloader

I’m using a custom compiled stk500v2 bootloader for an atmega2561 in an STK501/STK500 dev board. I burned the bootloader using an avrjtagmkII (I left the jtag fuse enabled). I modified the makefile for the cpu in use and for a 57600baud rate as well as an 8mhz clock rate. The very first time I tired to download a sketch it worked, but I can’t seem to overwrite the sketch. I tried erasing the chip with avrdude from the command line (which should only erase the non-boot section of flash) but still no good. What’s weird is that if I go and reflash the bootloader with the jtag, I can then download a sketch.

It seems that one of the changes made in version 1.0 of the Arduino IDE is that downloading a sketch first compiles it EVEN IF you have already used the compile (verify) option. As a result I can’t just press the reset button on the target and load the sketch since the bootloader seems to time out before the download starts. The stk500 has an rs232-ttl converter for tx and rx signals, and I’m using a USB serial dongle to connect it to my Linux computer. The dongle has ttl level outputs for DTR, DSR, CTS, etc. I could connect one of these to the cpu reset via a .1uf cap as is done on the Arduino targets (which signal does avrdude use? or is the reset sent from the IDE?).

Any ideas on why the STK500v2 bootloader isn’t working with my '2561 with the IDE? It DOES work from the command line IF I hit the return within a second of pressing the reset button on the STK500, so it appears that the bootloader times out and re-enters the previous sketch under the IDE, but NOT if the bootloader was just flashed.

NOT if the bootloader was just flashed.

If the bootloader was just flashed, the rest of memory would be erased (contains 0xFFFF) If the bootloader were to try to "start the sketch", it would jump into that string of 0xFFFF instructions (which is some non-jump instruction), and execute them one after another until ... the program counter reached the bootloader again.

Similarly, symptoms like yours can occur if you have not programmed the "start at bootloader" fuse. The AVR starts at 0, executes 0xFFFF instructions until it reaches the bootloader, and then runs the bootloader. Unless there is a real program at 0.

I'm also remembering some incompatibility between bootloaders and JTAG. But I haven't used JTAG, so it's not something I know about for sure.