Re: [avr-libc-dev] rjmp across FLASHEND

[Bernhard Kuemel]

Hallo Joerg!

On 10/07/2011 10:28 AM, Joerg Wunsch wrote:
> As Bernhard Kuemel wrote:
> 
>> My avr-gcc (debian/squeeze, gcc version 4.3.5 (GCC)), as it seems,
>> doesn't support rjmp across FLASHEND for ATmega168 (16K Flash):
> 
> Well, it's not the compiler but the linker that complains.

I thought so, but I removed this remark in my OP since I wasn't sure.

> As you can see, the overflow is only accepted for devices with <= 8
> KiB of flash ROM, in the assumption that the target address wraps
> around there.  (Actually, that address wrap around is not even clearly
> documented in the Atmel AVR instruction definitions; it can only be
> implied from the sentence that on devices with up to 8 KiB, the RJMP
> instruction can reach the entire memory.)

I could ask Atmel. They do respond to such questions. I'm pretty sure it
is ok to jump across flashend.

> If you want to extend the possible wrap around TOP/BOTTOM to larger
> devices, this check has to become more sophisticated in order to
> distinguish real overflow situations from wrap around situations.  As
> an additional problem, I'm not sure whether the linker has the
> required information (ROMEND) available at all to make that kind of
> decision.  Linking is done based on relatively coarse descriptions in
> the linker script, rather than actual per-device values.

I see, it's a little difficult.

> Why is this such a big problem to you?  On a device with 16 or more
> KiB of flash, I cannot imagine the two bytes saved by an RJMP
> instruction around TOP/BOTTOM really make such a big difference.

It's because of a mysterious bootloader I made :). Satisfied? No, you
want to know more :). Ok. But I don't want to talk too long about it. I
always have to.

I made a tiny bootloader. At 0 there is an rjmp -0x3c(PC) to the loader.
It's not a space problem, since unless one puts code in the interrupt
table there is space for a jmp instruction for each vector.

However, when the PC application that communicates with the bootloader
via the serial port, the bootloader is out of sync. The protocol, which
transmits 2 bits/serial byte, sends 0 value bits which get interpreted
as read flash word at address 0 and it keeps sending them until the
returned bits match the content of the word at address 0. Having a jmp
there would actually be preferable, since the first word were constant
then. But for smaller devices there must be an rjmp. In the loader there
is then an (r)jmp to the application. If the application starts within
2K of the rjmp, which is usually the case (across flashend again) I use
rjmp. Should the odd case happen, that the application starts beyond the
range of rjmp I have to use jmp in the loader. This makes the loader
bigger by one word and the reset rjmp changes by one word. So I have 2
different rjmps which I have to consider as sync word. I want to
minimize the number of sync words to make syncing most reliable. Maybe
that's not really an issue.

> 
> (The linker is part of the GNU binutils, so that's where to report
> this, if you want to file a bug report.)

I was wondering whether I'm bugging the wrong people ...

Thanks, Bernhard