Hi All...
Recently I was combining Optiboot (the hex file) with my application. The boot loader should load into the top, and my app into the bottom, but when combining the hex files I learned that Optiboot has a 2 byte data record at address 0000, which is causing a conflict with my application.
I don't think a boot loader should have any data in address 0000, but I am not a boot loader expert. Can anyone comment?
Thanks...
Reset vector. That's the only way for the bootloader to get control. Try swapping the images so the bootloader is after your application in the combined file. If that doesn't help, you may want to explain what "causing a conflict" means.
No, check out this app note:
http://www.atmel.com/Images/doc1644.pdf
Basically, the boot loader goes into the high space, and when you set the boot vector fuse (I forget what its called off the top of my head) it causes the uC to start at the beginning of where the boot loader is written. Then the boot loader transfers control to address 0 to start the app.
It turns out these two bytes of data are the version number, which westfw told me should be somewhere else, based on the linker command. So I'll investigate why it ended up where it is. I expect its safe for me to just delete that data record from the hex file before I combine it with my app, ans I'll test it to be sure.
This is all fixed. The data was the version number, and a change to the makefile moved that data. For those building their own optiboot, there is a makefile patch here:
http://code.google.com/p/optiboot/source/detail?r=cc5e4843feec1476610c5978b71b5e1023104d8d
Thank you for the follow-up.
(note that this was never a problem on "standard" arduino CPUs. It just showed up on a couple of the additional CPUs (644, 1284) that had had the version number support incompletely added.)