On lines 517/518, both address and eraseAddress are set to zero:
https://github.com/msproul/Arduino-stk500v2-bootloader/blob/master/stk500boot.c#L517
When we get a CMD_CHIP_ERASE_ISP, eraseAddress is reset to zero (properly):
https://github.com/msproul/Arduino-stk500v2-bootloader/blob/master/stk500boot.c#L903
When we get either a CMD_PROGRAM_FLASH_ISP or a CMD_PROGRAM_EEPROM_ISP, both address and eraseAddress will be zero.
https://github.com/msproul/Arduino-stk500v2-bootloader/blob/master/stk500boot.c#L919
This is, I would argue, incorrect behavior. Not all programs are uploaded to location zero. We specifically encountered this in our work with a small virtual machine (http://concurrency.cc/), where we upload the VM to address zero, and then upload the bytecode somewhere else in flash separately. This way, users can upload the VM once (~20K), and upload new programs (bytecode) many times without having to reflash the VM every time.
On the 168, 328, and 1280 everything has (in the past) worked fine. With the introduction of the 2560, our bytecode started clobbering the VM from address zero, despite providing location information to avrdude. We believe that the problem is in the bootloader. It seems like the bootloader puts the bytecode at the correct location (having extracted 'address' properly), but 'eraseAddress' remains initialized to zero, and therefore blocks are erased starting from address zero, while our bytecode is written into the correct location. Thus, the VM gets destroyed in the process of uploading bytecode.
I had a patch started, but do not have an ISP that works reliably on the Mac. If someone tells me what ISP to buy, I'll work on a patch.
On lines 517/518, both address and eraseAddress are set to zero:
https://github.com/msproul/Arduino-stk500v2-bootloader/blob/master/stk500boot.c#L517
When we get a CMD_CHIP_ERASE_ISP, eraseAddress is reset to zero (properly):
https://github.com/msproul/Arduino-stk500v2-bootloader/blob/master/stk500boot.c#L903
When we get either a CMD_PROGRAM_FLASH_ISP or a CMD_PROGRAM_EEPROM_ISP, both address and eraseAddress will be zero.
https://github.com/msproul/Arduino-stk500v2-bootloader/blob/master/stk500boot.c#L919
This is, I would argue, incorrect behavior. Not all programs are uploaded to location zero. We specifically encountered this in our work with a small virtual machine (http://concurrency.cc/), where we upload the VM to address zero, and then upload the bytecode somewhere else in flash separately. This way, users can upload the VM once (~20K), and upload new programs (bytecode) many times without having to reflash the VM every time.
On the 168, 328, and 1280 everything has (in the past) worked fine. With the introduction of the 2560, our bytecode started clobbering the VM from address zero, despite providing location information to avrdude. We believe that the problem is in the bootloader. It seems like the bootloader puts the bytecode at the correct location (having extracted 'address' properly), but 'eraseAddress' remains initialized to zero, and therefore blocks are erased starting from address zero, while our bytecode is written into the correct location. Thus, the VM gets destroyed in the process of uploading bytecode.
I had a patch started, but do not have an ISP that works reliably on the Mac. If someone tells me what ISP to buy, I'll work on a patch.