On Thu, Mar 14, 2013 at 10:09 AM, larry barello <la...@barello.net> 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
AVR-GCC-list@nongnu.org
https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
