On TI C2000™ F29x devices, the Hardware Security Module (HSM) controls which firmware the device accepts. The Safety and Security Unit (SSU) controls what that firmware may reach while it runs, according to a security configuration stored on the device.
Both are set up in one provisioning session of a few minutes, which C2Prog runs. Some of what it writes can never be changed.
This post covers the choices that go into the infrastructure behind that session, and what each one rules out afterwards.
The update path
The standard path is C2Prog’s own flash kernel, a small program loaded into the device’s RAM over JTAG or through the device’s UART boot mode, which programs the flash from there. A provisioned part can be programmed this way too, as long as the security configuration leaves JTAG or the UART boot mode open. A programming session halts the application and writes into the flash bank the application runs from.
JTAG and the UART boot mode both depend on hardware the product has to expose. JTAG needs a debug header with a probe on it. UART needs the boot pins brought out, so that something can drive them at reset.
The other path is a CodeSkin bootloader, a standalone program in its own reserved flash sectors. C2Prog sends it the image over the link the product already uses. The application enters the loader on a sequence received over that same link, so an update needs no probe and no boot pins. We call that touchless reflashing. It can also write into a bank the application is not running from. Our F29x loader is validated on serial. CAN, Modbus and the other transports we ship for F28x are scoped per project. Bank swapping can also be provided. So can switching the running core to the other bank without a reset, which keeps the application running while its code is replaced.
The flash kernel is C2Prog’s own code and runs from RAM, so the standard path leaves nothing behind on the device. A CodeSkin bootloader stays there. You buy it under a source licence, give it its flash sectors, and maintain it for the life of the product. That effort is justified where the product cannot be taken offline, or where it exposes neither a debug header nor a way to drive its boot pins.
The bank mode
F29x flash is divided into banks. The bank mode sets how those banks are assigned to the cores. It is committed when the device’s keys are written.
An F29H85x part can run application code on CPU1 and on CPU3. A device provisioned for CPU1 alone cannot be given flash on CPU3 later. The first question is therefore whether any firmware the product will ever ship uses the second core.
A bootloader that writes into a bank the application is not running from depends on the bank mode as well. It needs a bank kept free, which is flash the application cannot use. A device provisioned without a free bank cannot be given one later. The second question is therefore whether the product will ever be updated that way.
Both questions are about the product over its lifetime, not the firmware being built now. They have to be answered even where the roadmap has not settled them.
The signing keys
The device stores a hash of the public half of your signing key in memory that can be written only once. From then on it accepts only code signed with the private half. A device whose signing key has been lost can never be programmed again, so the key has to outlive the product.
A key generated inside a hardware token and never exported gives the tightest control over who can sign. Some tokens can copy a key to a second token and some cannot. That is settled when the key is generated, so a key created without a way to back it up has none.
A key held in a key-management system, with tokens issued to the people who sign, keeps the key recoverable and moves the custody question to that system. It fits where several people sign, or where the product will outlast the team that built it.
A key in a file on a build machine is for development.
A bootloader or a reference image from a supplier arrives unsigned. You sign it with your key alongside your own application, because the device accepts nothing else. Nobody can ship an image pre-signed for a family of devices. Handing the key to a supplier so that they can sign on your behalf also lets them sign your application.
The security configuration
The configuration sets which code may reach which memory and peripherals, whether the debug port opens, and whether flash can be written. It is the one part of the session that can be replaced later, provided it leaves the means of replacing it intact.
C2Prog reprograms a provisioned device through the same flash kernel, over UART or JTAG. The security configuration can close either of those. A configuration that blocks both produces a device nobody can reprogram.
The configuration also has to grant the flash kernel the memory and peripherals it needs to run. If one grant is missing, the device still accepts the configuration. The next attempt to reprogram it fails.
A configuration can also name who may replace it. In the strictest of the SSU’s modes that nomination is the only way to replace it, and a configuration that names nobody is final.
Before anything is written, C2Prog’s explain report gives UART and JTAG a verdict of OK or BLOCKED, names what stands in the way of a blocked one, and states whether the configuration can still be replaced at all. The verdicts apply to one revision of a configuration.
F29x Access Control with the SSU covers how a configuration is written and what the report contains.
Where we can help
We can set up the whole chain with you: the keys generated inside your token, the provisioning certificate that carries them into the device, the security configuration, a readable file written against your application’s memory map and peripherals, the explain report read together, and the signed file your production line will program.
Where the update path calls for one, we can write the bootloader as well and do the work to integrate it with your application.
If you are planning an F29x design, send us your part number, the cores you expect to use, and how the product will be updated in the field. Email info@codeskin.com, or see our secure loaders for the bootloader side.