On a standalone product, firmware is the whole story. On a networked one it is half of it. The other half is the set of values that describe where the node sits on its bus, and those values live in the same array as the program without being part of it.

The LPC2129FBD64 carries two CAN controllers, which makes it a common choice for gateways, drives and battery management boards. Recovering such a device means recovering the program and then recovering the network configuration that the program expects to find, because a node that cannot time its bits correctly is a node that cannot be verified.

What the network identity consists of

Four things define a node, and all four are usually in flash:

A byte-identical copy of the flash carries all four, which is why copying a node sometimes works and sometimes produces a device that answers nothing. The variables are the clock and the board, not the code.

Bit timing is a division problem

A CAN bit is built from a prescaler, two phase segments and a resynchronisation jump width, all derived from the peripheral clock the controller sees. That clock is not the core clock — on this family the peripheral bus runs at a fraction of it, selected at start-up, and firmware that changes the divider changes every peripheral timing at once.

For a bus running at a common rate with a common crystal, the arithmetic lands on well-known values. For a board with an unusual crystal, it can land on a combination that is legal but marginal, with a sample point that sits too early in the bit. Such a node works at room temperature on a short bus and fails on a long one, which is the classic description of an intermittent network fault that nobody can reproduce in the lab.

A recovered image settles the question, because the prescaler and segment values are written to the controller at initialisation and appear in the code as constants. Extract them, compute the resulting rate against the clock configuration the same image sets, and the node’s actual timing is no longer a guess.

Filters explain behaviour that looks like a bug

A node that receives everything and a node that receives nothing can differ by one mask value. The acceptance filter is a range check, and a single wrong bit in a mask turns a busy node into a deaf one.

When a customer reports that a replacement board runs but does not respond on the bus, the filter table is the second place to look, after the bit timing. In a recovered image it is a small group of constants written in a short initialisation sequence, and it is one of the few places in a stripped binary where the intent is unambiguous: the values map directly onto identifier ranges.

Recovering them is not just a repair aid. It documents the product’s place in the network, which is exactly the information a customer needs when the original integrator has disappeared and the bus protocol exists only as behaviour.

The error counters tell a story

CAN controllers maintain transmit and receive error counters, and their behaviour is diagnostic even without a logic analyser. A node whose transmit error counter climbs and then drops into bus-off is transmitting into a void: the identifiers are wrong, or the bit timing is, or nobody is acknowledging.

Reading those counters over the boot loader, on a device where the registers are accessible, is a cheap first measurement. Combined with a scope capture of the bus, it separates timing from addressing in a few minutes, which prevents the common mistake of rewriting the firmware to fix a hardware-level configuration error.

Recovering from a locked node

Where the device is protected, the network parameters are as inaccessible as the code, and the routes are the ones in LPC2129FBD64 port-level approach — the same family logic applies across these two ordering codes — and in LPC2101FBD48 protection states for what the control word allows.

Where the device answers, recovery is a read followed by an extraction step, and the extraction is where the value lies. A raw binary handed to a customer who does not know the bit timing solves nothing; the same binary with a table of register values, the derived bus rate and the filter map solves the problem completely.

The parameter block usually holds the rest

Node addresses, unit identifiers and calibration are typically kept in the emulated settings block rather than in code, so the recovery has a third component beyond program and timing. That block is described in LPC2119FBD64 parameter store work, and on a networked product it is worth reading before the code, because the values there often name the variant the firmware is running as.

Deliverable checklist

• full array image, trimmed and with the boot region excluded
• clock configuration as set by the reset code, with the peripheral divider
• bit timing registers, prescaler and resulting rate for both controllers
• acceptance filter and mask values, expressed as identifier ranges
• transmit identifiers found in code and in the parameter block
• parameter block content, interpreted
• the vector checksum confirmed

Seven items, and a customer with all seven can build a replacement node that the bus accepts. Six of them is a board that runs and a support call three weeks later.

A closing observation

Networked products fail in ways that look like software bugs and are configuration facts. The reason recovery work on this variant is more valuable than on a standalone device is that the configuration is usually undocumented — it lived in an integrator’s spreadsheet, or in a tool that was never shipped. Recovering it from the silicon is often the only remaining source, and it is a source that does not lie.

Comments are closed.