CODEWITHSUNDEEP
armbuild-processkeil
supercat
supercat

Reputation: 81247

How to set up build for multiple combined binaries

When working with embedded systems, it is sometimes necessary for a processor to be loaded with several independently compiled and linked binaries; in my present project, a processor is supposed to have both its own code image and a code image which it is supposed to transmit to remote devices with which it communicates. If I was programming the chip with a hex or binary file, I could use a batch file to simply concatenate the contents of separately built and linked files (perhaps using a "FIND /V" to remove things like Intel end-of-file records). When using the Keil debugger to program a device, however, the chip isn't loaded from such a file but instead from a .AXF file.

If the code image which should be sent to remote devices will change many times while I'm testing code for the main device (to which the debugger is attached), what would likely be the most useful way to set up the build process? My inclination would be to write a utility to convert a binary file of the remote processor's code to into either a C file containing const unsigned char REMOTE_CPU_DATA[] = {...}'; and configure the linker to locate that file's const section at the appropriate address, or else an ASM file containing absolute data directives, and then have that utility run as part of the build process for the main code, but converting binary data into text format for inclusion within a project seems icky. Also, would it be better to find a stock utility to do such conversion, or write a special-purpose one in something like C# or VB.NET (I could use either language, but primarily use the latter for PC development)? I would expect that ASM output would be Keil-specific, while C output would be development-system agnostic, but using C rather than ASM would require adding a line to the linker spec to set the absolute address of the remote CPU data [the address of the remote CPU data is fixed to allow it to be loaded under program control, but the hardware channel through which it will be loaded does not exist yet].

Upvotes: 5

Views: 2444

Answers (1)

artless-noise-bye-due2AI
artless-noise-bye-due2AI

Reputation: 22430

You may create a ELF file from a binary with objcopy like so,

objcopy -I binary -B arm -O elf32-littlearm --rename-section \
     .data=.remote.data remote.bin remote.elf

Then you can update your linker script like this,

.remote { 
     REMOTE_CPU_DATA = . ;
     *(.remote.data); 
}

Placing it where ever you like. The data is accessed from 'C' with extern char REMOTE_CPU_DATA[]; or however you wish to type the data. You can massage the endian of the binary with dd, etc.

Another way is to use the Gnu Assembler's .incbin directive as per Linux's firmware Makefile.

I don't know if the Keil tools can handle the ELF formats output by either objdump or gas. I think similar ideas may apply with the Keil tools if they have similar semantics.

Edit: This can also be done from a shell script with some *nix tools,

printf 'char REMOTE_CPU_DATA[] = {' && \
 hexdump -v -e '16/1 "0x%x," "\n"' remote.bin && \
 printf '};' > remote.c

Upvotes: 2

Related Questions