If you distribute firmware for TI C2000™ MCUs, whether to the field, to a
contract manufacturer, or just to a colleague at the next bench, the .ehx file
is the format to know about. It is the recommended way to hand off a programming
image for use with C2Prog.
What is an .ehx file?
.ehx stands for extended hex. Where a plain hex file contains only the raw
data to be programmed, an .ehx file also carries all of the MCU-specific
settings C2Prog needs to do the job: the target profile, memory layout, and
flash options.
It also bundles the binaries for the programming stages themselves: the primary
and secondary bootloading stages, such as the flash kernel and, on devices that
use it, the HSM runtime (HSMrt). These are the loaders that run on the target to
write your image into flash. Because they travel inside the .ehx,
there is nothing separate to match up or version alongside the file.
That makes an .ehx self-contained. The application image, the device settings,
and the loaders that put it there all travel inside a single file.
Why that matters
A raw firmware image is not enough on its own. To flash it, the person at the other end still has to know which device it targets and how C2Prog should be configured for it. A mismatch there leads to a failed or incorrect programming cycle.
An .ehx removes that guesswork:
- Nothing to configure. Whoever receives the file just loads it. The target settings travel with it.
- One artifact to track. A single file per build is easy to version, archive, and pass around.
- Fewer support cases. Field and factory operators have no settings to get wrong.
Password protection
An .ehx file can be password protected. This safeguards the file in transit:
to load and program it, the operator has to supply the password. It protects the
transport, not the firmware on the device.
For protecting the firmware image itself, pair the .ehx with a CodeSkin
secure bootloader. The image
can be encrypted at .ehx generation and is only decrypted once the bootloader
receives it on the target. The plaintext firmware never leaves your build
machine, so you can program through a contract manufacturer or in the field
without exposing it.
Creating an .ehx
You can produce an .ehx from the C2Prog GUI, or from the command line:
c2p-cli mkehx --target=28379,378,377,375D-CPU01_JTAG firmware.out
The --target option selects the C2Prog target profile that gets baked into the
file. Generating .ehx files from the command line is permitted under the free
Basic license, which makes it easy to produce one as part of a build.
See Flashing TI C2000 from Simulink with c2p-cli
for a build-flow example.
F29 devices: certificates at build time
On F29 devices, security is certificate-based rather than the code-security
module used on F28 parts. C2Prog handles this for you: the required certificates
are generated when the .ehx file is created, not at flash time. The
provisioning work happens once, on the machine that builds the image, and the
resulting certificates are written into the .ehx. The operator programming the part never has to generate
or manage certificates. For the full picture of how C2Prog handles F29 security,
see F29 Security Made Simple with C2Prog.
Programming from an .ehx
To program a target, load the .ehx in the C2Prog GUI, or flash it from the
command line:
c2p-cli load firmware.ehx --port=xds100v2 --print-progress
Loading from the GUI is available on the Basic license; command-line flashing is a Professional feature.
Questions about fitting .ehx into your release or production process? The
FAQ has more, and we’re happy to help.