Liniking external hex file to project

IoT Modules Development tools
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.

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.

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

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.

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:

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)

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

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?

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.

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:

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

12

Good news! :smiley:

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