Is there a way to exclude specific sections when generating a .bin file from a .out file? I can use the tiobj2bin to generate the bin file with all sections included just fine. I tried adding --exclude "fltext" to the %hexcmd% argument list in tiobj2bin.bat to try to exclude the fltext section, but it still includes it. I have played around with it a bit and it looks like the --exclude "fltext" switch only seems to work for me when I'm not using the --image switch. But I need an image, just an image without the fltext section.
My map is something like this. The fltext section is not valid memory and is only used as an indicator that it's that particular section during bootloading. I can create the proper binary by declaring the fltext section as type = NOLOAD and running the default tiobj2bin command, but I don't want to have to generate two separate out files just to get a bin file with fltext removed.
0x00000000 .text0x20000000 .bss0x70000000 .fltext
Any suggestions?
Thanks,
Andy
The fltext section should get excluded. But, when you are using the -image switch, the entire range of memory, as indicated by the ROMS directive in the auto-generated hex utility command file, is output to the binary file. For any memory range that does not correspond to a section in the .out file, a fill value of 0 is used. With regard to the fltext section, the corresponding memory range should be filled with 0. Are you seeing something else?
Thanks and regards,
-George
TI C/C++ Compiler Forum ModeratorPlease click Verify Answer on the best reply to your question.The Compiler Wiki answers most common questions.Track an issue with SDOWP. Enter your bug id in the "Find Record ID" box.
George,
My ROMS directive does include all memory (all_mem: o = 0x0, l = 0x700003dc) and the fltext section is filled with 0 in the final binary. I suppose you could consider the fltext section excluded in that case, but that's not really what I want. This still generates a 1.8GB bin file (mostly filled with 0).
I can generate the 256 KB bin file that I'm looking for by not linking in the fltext section in the first place, but my goal is to generate these 3 files using only one linker command script:app.out with or without fltextapp.srec with fltextapp.bin without fltext
I didn't see a way to generate the srec file without linking in fltext, so I linked it in. But I want to also be able to generate app.bin as if app.out did NOT have fltext linked in.
I can see that the ROMS directive is generated by mkhex4bin, but there don't seem to be any command line options available that would let me exclude the fltext section from the ROMS range. I think being able to do that would solve my problem.
Thanks for your help.
I see an issue you may not have considered. If the flext section is both skipped and not filled in the .bin file, then you have a hole in the output. How should such a hole be represented? How will the consumer of app.bin handle such a hole?
The only real ROM sections are between 0x00000 and 0x3FFFF, with fltext being the only thing placed beyond 0x3FFFF. If fltext is removed, it should be possible to shring the image to only what's left.
It turns out I can get the desired image using the gcc arm-elf-objcopy as follows:
arm-elf-objcopy.exe -O binary -R .fltext app.out app.bin
If the TI toolchain can do the same, that would be great.
Andy8086940The only real ROM sections are between 0x00000 and 0x3FFFF, with fltext being the only thing placed beyond 0x3FFFF. If fltext is removed, it should be possible to shring the image to only what's left.
Ah, I didn't think of that. Even though you are skipping a section, you don't end up with a hole in the output. That's because the skipped section is, in address order, at the end.
Andy8086940 It turns out I can get the desired image using the gcc arm-elf-objcopy as follows: arm-elf-objcopy.exe -O binary -R .fltext app.out app.bin
Well, one of the advantages of ELF object file format is that it enables use of non-TI tools just like this.
Andy8086940If the TI toolchain can do the same, that would be great.
I'm pretty sure I could get hex470 to do the same thing, but not as clean as that. I think you should stick with the GCC solution.