• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 82 subscribers
  • Views 1432 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Compiler: CCS settings for .bin generation

Giannis Roussos
Expert 2290 points

Tool/software: TI C/C++ Compiler

I need to automatically generate .bin files from my CCS projects (F28M3x specifically), which until now I do via a manual and error prone process.

I know that CCS already includes the tools necessary for this, however I have not found a complete guide on how they can be used for my purpose, just a few old threads.

Starting with the ARM core of F29M3x, the current process setup by a former colleague is as follows:

  1. Produce a .hex file with a post-build step with the command "${CG_TOOL_HEX}" -i "${BuildArtifactFileName}" -o "${BuildArtifactFileBaseName}.hex" -order MS -romwidth 32


  2. Run hex2bin v1.0.1 by Jacques Pelletier to convert the .hex to .bin

I am trying to automate the above using the ARM HEX utility integration in recent CCS versions.First I am trying to use the ARM HEX utility integration to produce just the hex file, but the resulting file has the oposite endiannes, unless I set memwidth and romwidth to 8, in which case some blocks are not aligned to 32bit address.

For the .bin file I have gathered from other incomplete threads that I need to use the undocumented -b option. However, this option is not  listed in the Assembly tools manual and very few info is available about it.

I will keep trying and post any progress, though I would appreciate any help from more experienced users.

  • 0
    Expert 2290 points

    Looking into generating the .bin directly with the ARM HEX utility (-b option), I have the following issue: If I do not use the -image option then the resulting .bin file contains non-contiguous data, i.e. it cannot be directly programmed to the flash. To solve this I understand I have to use the -image option, BUT this introduces two other issues:

    1. I have to create a configuration file with the ROMS info for the HEX utility. This file would essentially duplicate information already present in the linker command file, so changing the linker command file would mean that the HEX utility configuration may need updating too. If done correctly it would be extra work, if not (or not done at all) it would cause errors.
    2. In the ROMS directive used, I will have to define the whole Flash area available for program code (as already set in the linker command file), which combined with the -image option means that the resulting .bin file will contain fill values for all the flash, i.e. it will always have the maximum size of the flash program area. This is because the -image option causes the HEX utility to fill holes not only BETWEEN code sections but also BEFORE and AFTER. (The hex2bin utility I am using now seems to fill only holes between sections, i.e. creates the minimum contiguous .bin file). So at each firmware update I will have to upload a (possibly much) larger file than what is actually necessary.

    I would be really interested to know if the above issues can be handled with the HEX utility, as I would prefer it for a long term solution instead of third-party tools.

  • 0 in reply to Giannis Roussos
    TI__Mastermind 19810 points
    Giannis,

    did you check section 6.8.1.1 of the F28M35x device TRM (www.ti.com/.../spruh22h.pdf) I've put steps to create a bin file in CCS for using with M-Boot ROM. You can use same command to generate a bin file from the OUT file for flash.

    Let me know if that works, if not we can move the forum post to the tools team to get you help with what you are doing?


    Best Regards
    Santosh Athuru
  • 0 in reply to Santosh Athuru
    Expert 2290 points

    Hi Santosh,

    I didn't know this information was in the TRM, so thank you for that!

    I tried the post-build step in the ARM M3 project and the resulting .bin file is identical to the one created by my current process, except of the fill value which is 0xFF for hex2bin v1 and 0x00 for your post-build step. I verified that by updating to hex2bin v2 which allows changing the fill value.

    Before reading your reply I managed to also get the correct result using the ARM HEX Utility integration in CCS by manually adding "--order MS" to the armhex flags, which made the CCS-generated armhex command equivalent to the hardcoded one I was previously using as a post-build step, i.e. with the following flags (set via the ARM HEX Utility properties in CCS):

    --romwidth=32 --intel --order MS

    So the M3 side seems solved, and with 2 solutions available, either armhex + hex2bin or tiobj2bin.bat.

    Moving on to the C28 part, my process so far has been to program a chip via JTAG and the read back the flash into a .BIN file. I tried the same post-build step but it did not work, complaining that an ARM executable was missing. So I tried to match the correct format of the .BIN file using C2000 HEX Utility (hex2000.exe) and hex2bin and ended up with the following flags for hex2000 (set through the C2000 HEX Utility properties in CCS):

    --romwidth=16 --swapbytes --intel

    For the HEX to BIN conversion I had to update hex2bin to the newer version (linked above), which supports 16-bit words via the "-a" option.

    Hope this helps other people, though I think this information should be made available in the Wiki

  • 0 in reply to Giannis Roussos
    TI__Mastermind 19810 points
    Giannis,
    This helps, thanks for the clarifications and information. I will mark up your feedback to be looked at by the team.

    Best Regards
    Santosh Athuru