Liniking external hex file to project

#1

Hello
I’m new in OpenAT and Eclipse.
I have Open_AT_SDK_v4.24.
I have a question. Is there posible to link external file to my project. This external file is the program to MSP430 processor.
I want to read this from flash and send it to MSP via my implemented protocol (UART).
How can I specify address in flash to write that file.

Thanks.

0 Likes

#2

I’ve had to do this exact thing before. I think the easiest solution is to write a tool to convert the hex file into a C file that contains an array with the contents of the hex file. Then you can simply reference the array normally, instead of trying to work with a hard-coded address of the data.

If you’re using GCC (I haven’t used ADS) and if you do want to hard-code the address, I think the only way to specify the address would be by modifying the linker script. However, since the Wavecom build environment generates the linker script at build-time, you probably would want to check this out: viewtopic.php?t=2388. If you switch to using a Makefile as described by that link, then you can modify the linker script by following the documentation for GNU ld.

0 Likes

#3

Or find a ready-made tool which already does that! 8)

It’s quite a common requirement, so there must be a few around…

eg, try srecord.sourceforge.net

0 Likes

#4

Ahh, yes. I’ve used srecord often. Forgot to mention that. Lately, we’ve been doing too many custom modifications, so ready-made tools have been replaced with custom clones of those tools.

0 Likes

#5

Thnak you for reply.

I use first solution, but i have to write my own C-code generator because, my hex file have additional elements, not only hex numbers.

Thank you guys for help :slight_smile:

0 Likes

#6

Then it’d be best not to call it a “Hex file” - it’ll just lead to confusion…! :confused:

NB: most people will assume that "Hex file" means the standard Intel Hex format - so it’s best not to use that name for anything that isn’t in the standard Intel Hex format! 8)

0 Likes

#7

@awneil
You’re right, sorry for my ambivalence.

It’s exacly Texas Instruments TXT (MSP430) format.
I can use http://srecord.sourceforge.net for conversion. Great

0 Likes

#8

I’ve done that - but, looking at the map file, I think it might be using up a lot of RAM?

Using GCC, how do I ensure that the “hex” data goes into Flash (“code” space), and does not consume any RAM?
Does const do it?

0 Likes

#9

It depends on the environment. For the Wavecom, if you’re using a default linker script (see this post for an example: viewtopic.php?f=19&t=2388#p8847 ), then all data will end up in RAM. However, it’s not hard to add another section that maps some data to flash, then declare your array with attribute((section(".read_only_section"))).

In most projects I work on there’s no OS, so I have to write the code to copy data from flash to RAM before calling main. With that level of control, it’s even easier to leave large arrays in flash.

0 Likes

#10

Well, I tried

const unsigned char binary_image[] =
{
  0x00, 0x50, 0x00, 0x20, 0xa5, 0xc9, 0x00, 0x08, 0x2d, 0xca, 0x00, 0x08, 0x39, 0xca, 0x00, 0x08, 
  0x41, 0xca, 0x00, 0x08, 0x49, 0xca, 0x00, 0x08, 0x51, 0xca, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00, 
  :
  0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
};

And the binary_image does seem to end up in the .rodata section - which does seem to be ROM:

Memory Configuration

Name             Origin             Length             Attributes
ROM_MAP          0x00220000         0x00800000         xr
RAM_MAP          0x180c0000         0x00800000         !xr
*default*        0x00000000         0xffffffff

Linker script and memory map


.oat_header     0x00220000       0x62
 mos_header.o(.rodata*)
 .rodata        0x00220000       0x60 mos_header.o
                0x00220000                mos_BinHeader
 .rodata.str1.4
                0x00220060        0x2 mos_header.o
                                  0x4 (size before relaxing)

.text           0x00220064    0x31880
                0x00220064                PROVIDE (Image$$RO$$Base, .)
 *(.text)
 .text          0x00220064       0x84 mos_header.o
   :
   :
 .text          0x0023e780       0xfc /cygdrive/c/OpenAT/OAS201/IDE/GCC/4.0.1.1/bin/../lib/gcc/arm-elf/4.0.1/thumb/interwork/libgcc.a(_fpcmp_parts_df.o)
                0x0023e7b0                __fpcmp_parts_d
 *(.rodata*)
 .rodata        0x0023e87c     0xbe68 binary_image.o
                0x0023e87c                binary_image

Sorry to sound vague, but I’m not very familiar with these GCC mapfiles - can you recommend the best place to find out about them :question:

0 Likes

#11

Ahh, you’re right. It is in ROM. So you don’t need to play with the linker scripts at all.

I guess I’m so used to creating my own linker scripts for other reasons (hard-coded addresses, Harvard architecture, etc.), it doesn’t cross my mind that it might be overkill for some people. :wink:

Here’s the manual for LD, the linker:
sourceware.org/binutils/docs/ld/index.html
Here’s the scripts section:
sourceware.org/binutils/docs/ld/ … ml#Scripts
And the limited documentation on the map file (read about scripts to better understand the map files):
sourceware.org/binutils/docs/ld/ … 002dmap-62

0 Likes

#12

Good news! :smiley:

And thanks for the links. :smiley: :smiley:

0 Likes