Every device has a way in. On a part of this generation the way in is a boot loader held in ROM, selected by pin states at reset, which accepts a program over a serial interface and writes it into the array. The same routine is used at manufacture, at service, and — with modifications — at recovery.

That makes the loader the natural starting point for any work on the part: it is documented for the silicon, it exists on every device regardless of what the array contains, and it does not depend on the application being intact.

What the loader does

After reset, if the boot pins select loader mode, the ROM initialises the serial port to a fixed configuration and waits. It expects a defined frame format, a defined handshake, and a defined sequence of data records. Once the array is written, the ROM transfers control to the entry point.

Three consequences follow:

• The loader runs before any application code, so it works on a blank device and on a programmed one.
• It is not affected by the array’s protection state, because it writes rather than reads.
• It does not tell you what the array contains. A device in loader mode is a device with an open write port, not a device with readable memory.

Why the loader is not a read path

The loader’s job is to write. It accepts records addressed into the array and programs them. Nothing in the protocol returns previously stored data, because the manufacture case had no need for it.

This is the point where expectations go wrong. A device that accepts a new program through its loader is not therefore a device from which the old program can be recovered. The loader is a write-only door, and the fact that it opens does not mean anything behind it is visible.

What the loader does provide is a controlled way to change the device’s state. On a part where the array is protected and the goal is a working unit rather than an original image, loading a known program is a complete solution.

Recovering the loading configuration

The loader’s frame format and port settings are fixed but not always recorded. Recovering them from a device that no longer runs requires measuring the interface during an attempted load:

1. Reset the device with the boot pins in loader configuration.
2. Observe the transmit line. The ROM emits a synchronisation pattern before it expects anything.
3. Measure the bit rate from the pattern’s period.
4. Match the frame format to the ROM’s documented options.

Step two is the useful one. A device that transmits a synchronisation pattern on reset is a device in loader mode with a working clock and a working port — three facts established in one measurement, none of which require the application to be intact.

Clock and baud, and why they are coupled

The loader derives its bit rate from the device clock, which comes from a crystal or an external oscillator on the board. If the clock is wrong, the loader’s bit rate is wrong, and a host configured for the nominal rate sees framing errors rather than a failed device.

This produces a diagnosis trap. A board whose oscillator is out of specification, or absent, presents a device that appears not to enter loader mode. The device is fine; the timing is wrong. Measure the clock before concluding anything about the port.

What the part’s protection does and does not block

Reading the array from an external master is blocked when protection is applied. Writing through the loader is not, and neither is erasing.

That asymmetry defines the options on a locked unit:

• If a known program exists, the loader writes it and the device is restored. This is the common case in service work: a failed unit is reflashed from a production image.
• If no program exists, the loader gives a working but empty device. To obtain the original program, the array has to be read, and protection stands in the way of exactly that.

The distinction again separates restoring from reading. Neither is better; they answer different questions, and one of them is usually what the person actually needs.

Why this generation’s workflow looks the way it does

Products built around this part were manufactured with a fixture that held the boot pins, drove the serial port and streamed a program. That fixture is also the service tool. A vendor’s field procedure for a failed unit was: put it in the fixture, load the current image, test.

For anyone maintaining such a product now, reconstructing that workflow is often more valuable than recovering any individual device’s firmware. The fixture plus a known-good image restores units indefinitely; a recovered image restores one.

Practical notes

• The loader’s entry configuration is decided by pins, so a board that straps the pins for application boot needs those straps lifted to enter loader mode.
• Loading does not erase the whole array by default on every implementation; a program written over an existing one may leave sectors in a mixed state. Erase first, then load.
• After loading, confirm the entry point executes: the loader transfers control, and a program with a wrong entry address produces a device that appears to do nothing.

Related reading

• TMS320F243 and the same silicon in a different package — how peripheral differences change the analysis.
• TMS320F240 and protection at programming time — the sibling part’s security model.
• TMS320F280230 and the successor ROM — what the loader became on later parts.

FAQ

Can the loader read the existing program? No. It writes. The protocol has no read command.

Does read protection stop the loader? No. It writes and erases; protection governs reads.

How do I know a device is in loader mode? It transmits a synchronisation pattern shortly after reset.

Why does the host see framing errors? The device’s clock is wrong, or absent, so the derived bit rate differs from the nominal one.

Is loading the same as restoring? It restores a device to a known program. It does not recover what was there before.

Conclusion

The boot loader is the part’s most reliable interface: present on every device, independent of the array’s contents and unaffected by read protection. It is a write path, not a read path, and recognising that turns a locked unit into a solvable problem when a program exists and an unsolvable one when it does not — with the fixture, not the device, being the asset worth rebuilding.

Comments are closed.