Re: [avr-gcc-list] Boot loader issues

[Senthil Kumar]

On Thu, Mar 14, 2013 at 10:09 AM, larry barello <address@hidden> wrote:

I am implementing a boot-loader for the Xmega.  Actually I have a working
boot-loader, but I had to do some ugly things that I am sure there are
proper ways to do if I were not so ignorant.

Pointers to FAQ, samples or replies appreciated.  I did find the libc FAQ
and the gnu documentation on this subject.

1. How do I specify a long call from my application to jump into the
boot-loader (which resides at 0x20000).  This is my solution:

        case SMB_GOTO_BOOTLOADER:
                EIND = 1;       // HACK HACK
                ((void (*)(bool bCalled))((BOOT_SECTION_START)/2))(true);
                break;

 A simpler way is to define an extern function and then use -Wl,--defsym to set the address at link time. For example
➜  scratch  cat test.c
int main()
{
        extern void bootloader_func();

            bootloader_func();
}
➜  scratch  ~/avr/install/bin/avr-gcc -mmcu=atxmega192a3 -Wl,--defsym,bootloader_func=0x20000 test.c "

The emitted code will then look like this

00000204 <main>:
 204:    cf 93           push    r28
 206:    df 93           push    r29
 208:    cd b7           in    r28, 0x3d    ; 61
 20a:    de b7           in    r29, 0x3e    ; 62
 20c:    0f 94 00 00     call    0x20000    ; 0x20000 <bootloader_func>
 210:    df 91           pop    r29
 212:    cf 91           pop    r28
 214:    08 95           ret

The CALL instruction is capable of addressing the entire program memory. No indirect call either.

 

2. How do I get Studio 6 to not include the C startup files?  I know how
this works with older versions of Winavr but specifying -nostdlib (or
-nostartfiles) doesn't seem to work with studio 6 avr-gcc.  Currently I go
ahead and include gcrt... and accept the huge vector table (which I don't
use).

What is the version of the toolchain you are using (avr-gcc -v)? -nostartfiles should do the job.

3. The boot loader C runtime sets RAMPZ=1 but the compiler insists on using
indirect through Z to access I/O so it fails miserably in the boot section.
I solved this problem by wrapping my various I/O routines (init, TWI
handler, etc) with "RAMPZ=0; . RAMPZ=1;" Surely there is a better way.

The C runtime setting RAMPZ to 1 during startup was a bug, and was fixed in a later version of the toolchain. Again, what version of the toolchain are you using?

4. It appears that the boot-loader pushes 116 bytes of stuff into the end of
the APPTABLE section of FLASH.  It is avr-gcc jamming trampolines or
something there?  How do I make that go away?  I don't need the loader and
my applications fighting over that chunk of flash.

Hard to say without a map file. Can you paste the relevant contents?

Regards
Senthil