Anybody use the __attribute__ directive to do any absolute address
mapping in Keil?

I have a bootloader loaded in 0-0x4fff and my app code in 0x5000+. I
have a reserved 16 bytes in both sets of code (0x4ff0-0x4fff in the
bootloader and 0x5000-0x500f in my app). It holds version numbers and
anything else I need to store there.

I store the version number in 0x4ff0-0x4ff1 in the bootloader and
0x5000-0x5001 in my app code. They are compiled as:

const unsigned char bl_version[16] __attribute__((at(0x00004ff0))) {1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0};

AND

const unsigned char version[16] __attribute__((at(0x00005000))) {2,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0};

When I look in memory thru my Keil debugger, they are perfect, in the
correct location.

When I take the hex file and convert it to a BIN (HEX2BIN) so that I can
store on a SD card (for remote upload of new code), I noticed that in my
bootloader BIN that it doesn't put those 16 bytes at 4ff0. In fact, the
code stops where the bootloader actually ends. However, in memory in my
debugger, the memory is filled with FF all the way until 4ff0 where it
puts my 16 bytes correctly.

In the bin file for my app, the version is moved over to 5002, but it is
located in 5000 in memory.

Anybody know what the problem is? Funny thing is that I upgraded to
uVision4 a few months ago and I remember this working properly in
uVision3. It's like the linker has a problem or Keil changed something
somewhere.

--
Sutton

Start a New Thread

Have to use Fromelf instead of hex2bin. Forgot about that. Supposedly,
hex2bin doesn't work with ARM. But, maybe that's Keil.

Sutton

Sutton Mehaffey wrote:
>
>
> Anybody use the __attribute__ directive to do any absolute address
> mapping in Keil?
>
> I have a bootloader loaded in 0-0x4fff and my app code in 0x5000+. I
> have a reserved 16 bytes in both sets of code (0x4ff0-0x4fff in the
> bootloader and 0x5000-0x500f in my app). It holds version numbers and
> anything else I need to store there.
>
> I store the version number in 0x4ff0-0x4ff1 in the bootloader and
> 0x5000-0x5001 in my app code. They are compiled as:
>
> const unsigned char bl_version[16] __attribute__((at(0x00004ff0))) > {1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
>
> AND
>
> const unsigned char version[16] __attribute__((at(0x00005000))) > {2,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
>
> When I look in memory thru my Keil debugger, they are perfect, in the
> correct location.
>
> When I take the hex file and convert it to a BIN (HEX2BIN) so that I can
> store on a SD card (for remote upload of new code), I noticed that in my
> bootloader BIN that it doesn't put those 16 bytes at 4ff0. In fact, the
> code stops where the bootloader actually ends. However, in memory in my
> debugger, the memory is filled with FF all the way until 4ff0 where it
> puts my 16 bytes correctly.
>
> In the bin file for my app, the version is moved over to 5002, but it is
> located in 5000 in memory.
>
> Anybody know what the problem is? Funny thing is that I upgraded to
> uVision4 a few months ago and I remember this working properly in
> uVision3. It's like the linker has a problem or Keil changed something
> somewhere.
>
> --
> Sutton

--
Sutton Mehaffey
Lookout Portable Security
4040 Royal Dr.
Kennesaw, GA 30144
770-514-7999, 800-207-6269
Fax: 770-514-1285
http://www.lookoutportablesecurity.com
s...@lookoutportablesecurity.com

Start a New Thread

Hi Sutton,
Like you I’m having troubles with __attribute__ at(x).
It worked fine in uv3 but not in uv4.
For my 2103 project I wanted to place some device specific info in a
struct at the end of flash and then use an external app to update the
device specific values at the known address during manufacture.
This is working fine with uv3.
I have an open case with Keil.
I gave them a minimal project that shows the problem. It’s
interesting that the link either works or fails depending on if
another struct is included in the project or not.
(It also links fine if the absolute positioning is removed.)
The other struct is not absolutely positioned yet the linker complains
that there is no room left in flash when in fact there plenty of flash
available.
I see no logical reason why this should fail so I consider it a bug.
I’m waiting on Keil to confirm and provide a fix other than their
current suggestion of changing the absolute position and wasting space
at the end of flash.

Cheers ...Laurie:{)

On 11/03/2010, at 1:49 AM, Sutton Mehaffey > wrote:

> Anybody use the __attribute__ directive to do any absolute address
> mapping in Keil?
>
> I have a bootloader loaded in 0-0x4fff and my app code in 0x5000+. I
> have a reserved 16 bytes in both sets of code (0x4ff0-0x4fff in the
> bootloader and 0x5000-0x500f in my app). It holds version numbers and
> anything else I need to store there.
>
> I store the version number in 0x4ff0-0x4ff1 in the bootloader and
> 0x5000-0x5001 in my app code. They are compiled as:
>
> const unsigned char bl_version[16] __attribute__((at(0x00004ff0))) > {1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
>
> AND
>
> const unsigned char version[16] __attribute__((at(0x00005000))) > {2,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
>
> When I look in memory thru my Keil debugger, they are perfect, in the
> correct location.
>
> When I take the hex file and convert it to a BIN (HEX2BIN) so that I
> can
> store on a SD card (for remote upload of new code), I noticed that
> in my
> bootloader BIN that it doesn't put those 16 bytes at 4ff0. In fact,
> the
> code stops where the bootloader actually ends. However, in memory in
> my
> debugger, the memory is filled with FF all the way until 4ff0 where it
> puts my 16 bytes correctly.
>
> In the bin file for my app, the version is moved over to 5002, but
> it is
> located in 5000 in memory.
>
> Anybody know what the problem is? Funny thing is that I upgraded to
> uVision4 a few months ago and I remember this working properly in
> uVision3. It's like the linker has a problem or Keil changed something
> somewhere.
>
> --
> Sutton Start a New Thread

Hi Scott,
The Keil offered solution for me was to create a new region in flash
by splitting the existing region in projects/options. The new region
is at the fixed location and large enough to hold the fixed location
object.
Then move the C declaration for the object to it's own C file and
change the properties of the file to assign it to the new ROM region.
__attribute__ is no longer needed then.
...Laurie:{)

On 11/03/2010, at 1:49 AM, Sutton Mehaffey > wrote:

> Anybody use the __attribute__ directive to do any absolute address
> mapping in Keil?
>
> I have a bootloader loaded in 0-0x4fff and my app code in 0x5000+. I
> have a reserved 16 bytes in both sets of code (0x4ff0-0x4fff in the
> bootloader and 0x5000-0x500f in my app). It holds version numbers and
> anything else I need to store there.
>
> I store the version number in 0x4ff0-0x4ff1 in the bootloader and
> 0x5000-0x5001 in my app code. They are compiled as:
>
> const unsigned char bl_version[16] __attribute__((at(0x00004ff0))) > {1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
>
> AND
>
> const unsigned char version[16] __attribute__((at(0x00005000))) > {2,1,0,0,0,0,0,0,0,0,0,0,0,0,0,0};
>
> When I look in memory thru my Keil debugger, they are perfect, in the
> correct location.
>
> When I take the hex file and convert it to a BIN (HEX2BIN) so that I
> can
> store on a SD card (for remote upload of new code), I noticed that
> in my
> bootloader BIN that it doesn't put those 16 bytes at 4ff0. In fact,
> the
> code stops where the bootloader actually ends. However, in memory in
> my
> debugger, the memory is filled with FF all the way until 4ff0 where it
> puts my 16 bytes correctly.
>
> In the bin file for my app, the version is moved over to 5002, but
> it is
> located in 5000 in memory.
>
> Anybody know what the problem is? Funny thing is that I upgraded to
> uVision4 a few months ago and I remember this working properly in
> uVision3. It's like the linker has a problem or Keil changed something
> somewhere.
>
> --
> Sutton Start a New Thread