avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] linker issue, resolving a pointer as uint32_t


From: Torsten Mohr
Subject: Re: [avr-gcc-list] linker issue, resolving a pointer as uint32_t
Date: Wed, 29 Jun 2005 00:40:14 +0200
User-agent: KMail/1.8

Hi,

thanks for your comments.

> You read the pointer from flash memory and the value you get is the
> value of the pointer. It is up to you whether you use it as a pointer to
> data or flash memory.

As i see it i'm not really free to choose, the pointer in flash is restricted
to the lower 64k.  The example i gave is not made up, i really wanted
to implement it that way.  The structure at a certain address should
provide some information for the bootloader about the application.
The bootloader would use that information to tell if the application is
valid and can be started - or not.

With 16 bit pointers i can only download 64kByte programs at
maximum.  At the moment i don't yet have that, but i want to implement
it right from the beginning the way it should be, so i'd like to be able
to check 128kB addresses.  How else should i construct the uint32_t
that pgm_read_word_far needs?

const uint32_t app_info_end __attribute__ ((section(".fini0"))) =
 APP_INFO_END;  // place a special number at the end of the program

const APP_INFO app_info __attribute__ ((section(".vectors"))) = {
  APP_INFO_MAGIC,
  1,
  &app_info + sizeof(APP_INFO),
  &app_info_end,  // place a pointer to that special number for checking
  0xadde,
  "a_____b",
  "c_____________________________d"
};

> > Can i then somehow tell if this pointer is in the lower or the upper
> > 64k of my ATmega128?
>
> All pointers are only 16bit. As I know, linker will place all data in
> flash to the bottom 64k part. I don't know about any support from linker
> for the data stored in flash memory above 64k.

Ok, but with the example i explicitly _want_ app_info_end to be placed
after all the other data in flash.  Only if the special value APP_INFO_END
is found at the end of the program the bootloader can be sure that the
application is programmed completely.

Also, from looking into binutils, i see that pointers are only 16 bit.
But i see that as a big restriction.  Isn't there a way to get around
that?

> > Is the linker at some level capable of resolving this?  It somehow
> > has to be able to do this, it can resolve calls between the lower
> > and upper 64k, so the information must be available somewhere.
>
> Every instruction in AVR is 2byte or 4byte long and they are addressed
> as words. Thus it is possible to address the whole 128kB of flash memory
> with only 16bit pointers. Problem occurs only when data are read from
> flash.

Yes, but this only applies for the PC, to place the PC on an odd address
doesn't make sense.  For data pointers, _more_ than 16 bits would make
sense.

On other architectures i chose the structure above to describe the
application for the bootloader, is there some other way to do the same?
I don't see how it could be done with 16 bit pointers, but if anybody
can give me a hint that would be great.


Best regards,
Torsten.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]