A hundred kilobytes of code and forty bytes of constants arrive in the same file, and the forty bytes are worth more. That is not a rhetorical point. Code can be rewritten, disassembled, compared against a sibling product and reconstructed. A calibration offset measured on a production fixture against one particular shunt resistor, at one temperature, cannot be reconstructed from anything.

The RX62T group is built for exactly this kind of product: two twelve-bit converter units, a six-channel motor timer, and an output-enable block that can disable the inverter without the core being involved. Products built on it measure current through shunt resistors and reconstruct phase currents from them, and the accuracy of that reconstruction depends entirely on constants that were measured once.

R5F562TAADFP#11 is one of the larger-memory order codes, with a QFP-type package field and a quality code that differs in format from the version codes seen elsewhere in the family. That difference of format is worth noting only because it is a reminder that these suffixes are not one scale.

What calibration items exist

The first row is the one that must be preserved bit-exactly. An offset that is wrong by a few counts produces a torque ripple that a customer will describe as a mechanical problem, and it will be investigated as one for weeks.

Why they cannot be regenerated

Three reasons, and any one of them is sufficient.

The constants depend on the physical components on that board: the shunt resistance, the amplifier’s input offset, the divider tolerances. Two boards from the same production run differ, which is precisely why the fixture measured each one.

The constants depend on the measurement conditions the fixture used, including the temperature and the supply at the time. Reproducing the number requires reproducing the fixture.

And on some designs the constants are not measurements at all but corrections derived from a test that also stores results elsewhere, so the number is meaningful only in combination with the test record.

A recovery that returns the table without saying what each entry is a correction for has returned data, not information. The mapping matters as much as the values.

Finding them in an image

Four markers, and they usually appear together.

A small table of signed sixteen-bit values that are all close to zero but not zero is the classic offset table, and it is almost impossible to mistake for anything else once seen. Real code and real strings do not produce a run of values like minus three, plus one, minus seven, plus two.

The table is referenced by the initialisation code, so a literal pointing at it appears in the startup path, close to the converter configuration.

It is written by code that runs once, under a condition — a first-power-up flag, an uninitialised-memory check, or a diagnostic command. That condition is the tell that distinguishes calibration data from a lookup table.

And it sits in the data region rather than in the constant region of the code, because it is written at run time on the fixture and the linker reserved space for it.

What happens when it is lost

Three outcomes, in increasing cost.

If the customer has the production test records, the values can be re-entered and verified against a known-good unit. This is the cheap case and it depends entirely on whether those records still exist.

If the fixture still exists, the unit can be recalibrated. This is a production engineering task, and the customer may not have the fixture any more, which is common on products older than ten years.

If neither exists, the only route is a sibling unit of the same batch, with the acceptance that the offsets will be close but not identical. That is a real engineering compromise and it should be described as one rather than presented as a recovery.

Delivering calibration as a table

The form that a customer can act on has four columns: parameter, raw value, physical unit, and the address it was read from. The fourth column is what lets them verify against their own records, and the third is what makes the value meaningful.

Alongside it, one paragraph stating what each parameter corrects and, where it is known, the conditions under which it was measured. Where it is not known, say that instead — a calibration constant whose measurement conditions are unknown is still useful, but it is not a specification.

For the data region as a whole, R5F562T7ADFF EEPROM covers locating it. For the code that consumes these constants, R5F562T7DDFF flash covers reading it block by block. And for a much smaller part where the same problem appears as a single factory trim word, PIC12C508A firmware makes the point at the other end of the scale.

FAQ

Are these constants part of the firmware? They are stored in the same flash and written by a different process. That distinction is the whole subject of this page.

Can they be copied between units? Copied, yes. Correct, no. Two units of the same batch will be close and not identical.

Does losing them make the product unusable? It makes it out of specification. Whether that matters depends on what the product measures, and on a current-controlled drive it usually does.

The short version

The code is the bulk and the calibration is the cargo. Look for a small signed table referenced from the initialisation path, confirm it is written once under a condition, and deliver it with units and provenance. Then say plainly what happens if those numbers are lost, because that sentence is usually the reason the recovery was commissioned.

Comments are closed.