Re: Boot loader issues

On Thu, Mar 14, 2013 at 10:09 AM, larry barello <[email protected]> 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

_______________________________________________
AVR-GCC-list mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list