Pages: [1]   Go Down
Author Topic: OptiBoot for 1284P and address 0000  (Read 864 times)
0 Members and 1 Guest are viewing this topic.
Smithfield, Rhode Island
Offline Offline
God Member
*****
Karma: 3
Posts: 843
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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...


Logged

Global Moderator
Dallas
Online Online
Shannon Member
*****
Karma: 207
Posts: 12921
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset


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.
Logged

Smithfield, Rhode Island
Offline Offline
God Member
*****
Karma: 3
Posts: 843
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset


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.

 
Logged

Smithfield, Rhode Island
Offline Offline
God Member
*****
Karma: 3
Posts: 843
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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

Logged

Global Moderator
Dallas
Online Online
Shannon Member
*****
Karma: 207
Posts: 12921
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset


Thank you for the follow-up.
Logged

SF Bay Area (USA)
Offline Offline
Tesla Member
***
Karma: 133
Posts: 6755
Strongly opinionated, but not official!
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

(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.)
Logged

Pages: [1]   Go Up
Jump to: