None of the five problems below is exotic. Each one costs days when it goes unnoticed, because a hidden assumption looks true on the bench until the moment it isn’t.

In this article I walk through five lessons from taking an i.MX RT (Cortex-M7) control unit along that path, in the order a product meets them: the mechanism behind each one, and the rule that keeps it from coming back.

1. The board boots on its own, then dies behind the bootloader

The mental model: the boot ROM was quietly doing your setup for you.

A stand-alone application image on the i.MX RT works because the boot ROM reads the image’s boot header and runs its DCD (Device Configuration Data). That is where external SDRAM gets configured. You never have to think about it.

Then you put a bootloader such as MCUboot in front of the application. A signed application image behind a bootloader has no boot header of its own, so nobody runs its DCD. The first stack push or the first .bss clear in SDRAM ends in a bus fault, long before main().

The fix has two parts:

1. Move the SDRAM setup (the DCD) into the bootloader, which the ROM still boots normally.
2. Make the application skip the clock (PLL) re-initialisation, because the bootloader has already done it.

A related trap: in MCUboot’s direct-XIP-with-revert mode, a slot without the image trailer’s magic value is erased at reset. The symptom is the application disappears after a power cycle. Sign the image with the trailer included.

2. Measure the chip, not the documents

The mental model: the flash size is a measurement, not a setting.

The flash size in a linker script, a ticket or a code comment is often copied from an earlier board. Several documents agreeing with each other proves nothing if they all come from the same assumption. Read the part number on the board, and probe the memory with a debugger before you plan a partition map around it.

Then make the answer structural, so it cannot drift again:

1. One header owns the flash partition map.
2. A start-up assert checks it against the linker symbols.
3. A host test parses the linker scripts, so any drift fails in CI rather than on a customer’s device.

The map matters most once you plan field updates. A dual-slot layout needs room for two complete images, next to the bootloader and the data partition, and images grow over a product’s life.

3. Writing the flash you execute from

The mental model: while the flash is busy, it does not exist.

On the i.MX RT the code usually runs straight out of QSPI NOR (execute in place, XIP). A firmware update writes to the same chip. From the moment you send a program or erase command until the flash clears its busy bit (WIP), nothing may be fetched from it: not the interrupt handler, not the vector table, not a helper function the compiler decided not to inline.

The failure is intermittent, which makes it nasty. The update crashes at a different block on every run, and every bench session looks like a different bug.

What fixes it:

1. Run the erase and program routines, and everything they call, from RAM.
2. Keep interrupts masked while the flash is busy. Check the datasheet for how long that is: a page program is short, but a sector erase takes tens of milliseconds, and the worst case is many times the typical value.
3. Invalidate the instruction cache afterwards. The Cortex-M7 fetches speculatively and can have pulled in stale or garbage lines during the write.

4. Treat the field update as a protocol

The mental model: every update request ends in exactly one outcome, and the new version number is the only proof.

A device that reports “update done” has proven nothing. It might reboot into the old image, or not reboot at all. Update logic only gets robust once you treat it as a protocol with explicit rules:

• Every request ends in exactly one outcome: success, a classified failure, or a timeout. Never silence, never two answers.
• After the restart, poll the device for its version with a fixed interval and a hard limit. Only the new version string counts as success.
• Retries must fit the device’s own limits. If the target closes an idle session after a timeout, all your retries together must finish inside it, or the retries themselves break the session.

The bench catches what unit tests cannot: a bootloader step on the target that takes far longer than you assumed, or a frame buffer that does not fit on the task stack you gave it. Measure step times on hardware and check stack high-water marks before you trust the timeouts.

5. Production-ready means surviving the power cut

The mental model: measure the hold-up time before you design the software around it.

When the supply drops, the board runs a little longer on its capacitors. That hold-up time is a hardware property: measure it on a real board, in the worst-case load state, before you design the power-fail path. One wrong part in the hold-up circuit can bring it close to zero.

That number decides the software design. If the worst-case flash erase (lesson 3) is longer than the hold-up time, the emergency path must never start a flash operation. It only finishes or abandons what is already running, and closes the file system.

Then test it properly. Cut power repeatedly while the firmware writes continuously, and check after each cut that the file system is consistent and the last committed version of each file survived.

Summary

1. Own what the ROM did for you. Once a bootloader sits in front, it has to set up memory and clocks.
2. Measure, then make it structural. Flash size, step timings and hold-up time are measurements; a header, an assert and a CI test keep them true.
3. Design for the worst case. The flash write path runs from RAM, updates end in exactly one outcome, and the power-fail path never starts an erase.

💬 Questions, corrections, or your own war story? Leave a comment below.

The concept is simple. Production is not, because almost every step is one-way. A fuse bit can go from 0 to 1, never back. Burn the wrong value, or burn the right values in the wrong order, and a board on the line becomes scrap. For a product team, the order of the steps matters more than any single step.

In this article I give the checklist I use, in the order that keeps every step recoverable for as long as possible, with the reason behind each one.

The checklist at a glance

The first four steps can be repeated as often as you like. That is where all the testing belongs.

0. Draw the trust boundary first

Decide who is allowed to hold secrets before you generate a single key. My split: the contract manufacturer (EMS) assembles and tests boards with an unsigned test image and no keys. Boards leave the EMS open, with no secrets on them. Signing, fusing and device identity happen in-house.

That one decision keeps the private keys inside one building and makes every later step auditable.

1. Keys: only a hash goes into the chip

HAB uses a small tree of keys. The SRK (Super Root Key) sits at the top. It certifies a CSF key, which signs the command sequence, and an IMG key, which signs the image. The chip stores only a hash of the SRK public keys, in the SRK_HASH fuses.

With NXP’s SPSDK the key tree is one command. Without -ca you only get SRKs, which is not enough to sign:

nxpcrypto pki-tree hab -k rsa2048 -o keys -ca

Two rules matter more than the tool:

1. The private keys never live on a laptop that leaves the building. An HSM is the right home.
2. Choose the key size for the product’s lifetime, not the tutorial. HABv4 supports RSA from 1024 to 4096 bits. Most examples, including mine above, use RSA-2048. NXP’s AN13023 notes that BSI guidance does not accept RSA-2048 for new designs, while RSA-3072 is fine. If your product goes through that kind of review, decide before you fuse anything.

2. Sign the image

In SPSDK 2.0 (October 2023) the old tool names changed: elftosb became nxpimage, and nxpkeygen/nxpcertgen became nxpcrypto. Old tutorials fail quietly because of it.

nxpimage hab get-template -f mimxrt1060 -o hab_template.yaml
nxpimage hab export -c hab_template.yaml -o signed_image.bin

HAB signs a digest of the image. It does not encrypt it. Encryption is a separate step (step 5).

3. Boot the signed image on an open part

This is the step that prevents the most common production brick. Before any fuse is burned, erase the flash, program the final signed image, and boot it on a part that is still open.

In the open configuration HAB checks the signature but only logs a failure and boots anyway. That makes it the perfect test bench: you see every problem in the HAB event log, and the board still works. Do not move on until the log is clean.

4. Burn the SRK hash and check again

Now burn SRK_HASH, reboot, and check the HAB log a second time, this time against the fused hash. The part is still open, so a mistake here still boots. It just means this chip can never be closed with your keys.

5. Encrypted XIP: decide early

Signing proves who wrote the firmware. Anyone with a flash programmer can still read it. If the code itself is worth protecting, the i.MX RT106x can run encrypted code straight from flash with its BEE (Bus Encryption Engine): AES-128, two regions, decrypted on the fly while executing. Other RT10xx parts use OTFAD instead, and the RT1010 has neither.

The fuses involved are BOOT_CFG1[1], which enables encrypted XIP, and the key-select fuses BEE_KEY0_SEL / BEE_KEY1_SEL. These pick either a key derived from the chip-unique OTPMK or a key you burn yourself into SW_GP2.

One more trade-off: encrypted XIP does not work together with flash remapping. If you use MCUboot, that rules out its swap-by-remap mode and leaves overwrite-only updates, without a rollback slot.

6. Close the part

Burning SEC_CONFIG[1] closes the part. From then on, an image that fails authentication does not run: the boot ROM drops into the serial downloader instead.

My policy: the first batch stays open with the SRK fused, so it can still be recovered. Volume units are closed only after the full end-of-line test has passed on them.

Two details are easy to miss:

• Closing does not disable the USB serial downloader (SDP). A separate fuse, SDP_DISABLE, does that. I leave SDP enabled on purpose, as a recovery path.
• On a closed part the boot ROM enables the MPU. A debug or flash tool that worked before may need to disable it first.

7. Lock the debug port and the fuses, last

An open JTAG port bypasses everything above. The i.MX RT1060 Security Reference Manual describes three modes in the JTAG_SMODE fuses: enabled, Secure JTAG (challenge-response), or no debug. SJC_DISABLE gives the strongest protection. The manual also requires the KTE fuse to be burned, or the JTAG mode does not take effect.

The very last step is the lock fuses (BOOT_CFG_LOCK, SJC_RESP_LOCK, the GP locks and others), which stop anyone from burning more bits later. And never burn a reserved fuse.

Who checks what at runtime

A common question once MCUboot is in the picture: does HAB verify every application update? No. HAB verifies the bootloader at every reset. The bootloader then verifies the application with its own signature (ECDSA P-256 in my setup). That means two sets of signing keys, and both belong behind the same trust boundary from step 0.

Summary

1. The order is the safety net. Everything reversible (keys, signing, testing on an open part) happens before anything one-way.
2. Signing is not encryption. HAB proves origin. BEE hides the code, and on the RT106x it comes with a decrypt-only catch for updates.
3. Close late and in stages. First batch open with the SRK fused, volume units closed after their full test, debug and fuse locks last.

💬 Questions, corrections, or your own war story? Leave a comment below.