This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Tool/software: TI C/C++ Compiler
Target Device TMDSEVM6678 / TMDSEVM6678LE
Hi All,
I have come across the below links on how to link a binary resource (eg. an image, or an array of 8-bit data) into an executable, however, the are pretty old.
I know I could do that with gcc linker using ld command ... ( ld -r -b binary -o outfile.o infile.bin )
but I am wondering if there is such feature in C6000 ti compilers (eg 8.3.x )
Please let me know if you are aware of such utilities ... I just tend not convert the binary into c code and then compile; particularly because the binary data is pretty huge for my case (140mb) and compilers could crash (I have had that experience with QT MinGW gcc).
Any update on such utilities or a feasible workaround is much appreciate it.
Regards
Mike ITGeek said:I know I could do that with gcc linker using ld command ... ( ld -r -b binary -o outfile.o infile.bin )
but I am wondering if there is such feature in C6000 ti compilers (eg 8.3.x )
Unfortunately, no.
The second link in your post shows a method for using objcopy to change a binary file into a C6000 object file. I have never used that method. But it looks to be worth a try.
Thanks and regards,
-George
That actually worked for a small binary file just fine (I would test for a huge file too...)
I got the below warnings too which I am not sure what they mean since I am more of a software developer (I haven't had that much of embedded programming experience up until recently)
arm-none-eabi-objcopy --alt-machine-code=140 --input-target=binary --output-target=elf32-little test.bin Debug/test.obj
arm-none-eabi-objcopy: this target does not support 140 alternative machine codes
arm-none-eabi-objcopy: treating that number as an absolute e_machine value instead
Let me know if you have any comments.
Regards
The bottom line is you can ignore these diagnostics ...
Mike ITGeek said:arm-none-eabi-objcopy: this target does not support 140 alternative machine codes
arm-none-eabi-objcopy: treating that number as an absolute e_machine value instead
The most recent online documentation for objcopy has this description for the option --alt-machine-code ...
If the output architecture has alternate machine codes, use the indexth code instead of the default one. This is useful in case a machine is assigned an official code and the tool-chain adopts the new code, but other applications still depend on the original code being used. For ELF based architectures if the index alternative does not exist then the value is treated as an absolute number to be stored in the e_machine field of the ELF header.
The last sentence applies. The value 140 is stored in the e_machine field of the header for the output object file. To know that this is correct, consult the C6000 Embedded Application Binary Interface Application Report. Search for e_machine to find the following ...
An object file conforming to this specification must have the value EM_TI_C6000 (140, 0x8c).
For further confirmation, use the C6000 utilities ofd6x and nm6x to dump the details in the object file created with arm-none-eabi-objcopy. I did this experiment on a small example, and I did not find any problems.
Thanks and regards,
-George