NOTICE: The Processors Wiki will End-of-Life in December of 2020. It is recommended to download any files or other content you may need that are hosted on The site is now set to read only.

Tiobj2bin Failed

From Texas Instruments Wiki
Jump to: navigation, search


This article has moved to here. This older article remains here for legacy reasons.


You are here because are seeing a diagnostic similar to:

tiobj2bin.bat failed on \some\path\bin\ofd470.exe
Please see

This page gives the full context of this diagnostic.


This section presumes you aren't even aware you ran the DOS batch file tiobj2bin.bat. Such is often the case.

Some systems require that the executable be programmed into flash memory. The software which does this programming does not accept the executable object file (the .out file) produced by the linker. Instead, it expects a much simpler binary file. The batch file tiobj2bin.bat converts the executable object file into the binary file. A post-build step in the CCS project invokes tiobj2bin.bat with the proper arguments.

The details of how tiobj2bin.bat works are best learned by reading the file. For now, it is enough to know that important steps in the process are carried out by these tools:

  • OFD
    • Object File Display utility
    • Typical name: armofd.exe
    • Found in the \bin directory of the compiler tools
  • HEX
    • Hex conversion utility
    • Typical name: armhex.exe
    • Found in the \bin directory of the compiler tools

As for tiobj2bin.bat itself ...

What Failed

The TI ARM compiler tools changed the names of the executables starting with release version 5.0.0. Among other changes, ofd470.exe changed to armofd.exe, and hex470.exe changed to armhex.exe. Consider what happens with an older CCS project which has a post-build step that uses tiobj2bin.bat. That post build step still invokes ofd470.exe and hex470.exe by name. Fortunately, tiobj2bin.bat detects when this happens, and automatically changes the name ofd470.exe to armofd.exe. The same is done for hex470.exe and armhex.exe.

If you see the diagnostic above, then the part of the script which changes these executable names has failed. The command name shown in the diagnostic is the original form of that command before any change. For reasons unknown, neither of ofd470.exe or armofd.exe can be found. Or, perhaps neither of hex470.exe or armhex.exe can be found. If a full directory path to the executable is supplied, then that directory is searched. If no directory path is supplied, then the system path is searched.

Here is one way this circumstance may occur. A CCS project is started using the TI ARM compiler. At some later point, the compiler is changed to the GCC ARM compiler. This change may be applied to an existing build configuration, or by adding a build configuration. Either way, the updated or new build configuration inherits many properties from the initial build configuration. One of these properties is referring to armofd with something like ${CG_TOOL_ROOT}/bin/armofd . When the build configuration changes, the variable CG_TOOL_ROOT changes from a TI compiler location to a GCC compiler location. The GCC compiler location has neither armofd or armhex. Thus, you see the diagnostic.

The solution in this case is to change how the binary file is created. No longer use tiobj2bin.bat, but use GCC objcopy instead. Delete the post-build step, and instead use the GNU tool's objcopy utility to convert the .out to binary. You can do this in CCS by going into Project Properties->Build->GNU Objcopy Utility. Enable the utility and then set the option to convert to binary.

Configure GCC ARM objcopy