Going from a hundred pins to eighty costs general-purpose I/O and some convenience. Going from eighty to sixty-four costs channels — and channels are different, because a design can absorb losing a spare port pin and cannot absorb losing the eighth sensor input it was built around.

That is what makes the sixty-four-pin body the interesting member of this group. It is the point at which the capacitive touch interface and the converter stop being described by the silicon and start being described by the package.

The same peripheral with fewer electrodes

The touch sensing unit is the second generation of Renesas’ capacitive block: self-capacitance and mutual-capacitance modes, automatic judgement, multi-frequency scanning to dodge noise, and the ability to run in a low-power state and wake the core.

None of that changes with the package. What changes is how many electrodes can be connected, because each electrode occupies a pin, and the pins that reach the touch multiplexer are a subset of the package’s pins.

The same is true of the converter. Nineteen channels exist in the design; how many of them are bonded out depends on how many pins the package has, and the higher-numbered channels are the ones that go first.

The scan table is a data structure in flash

A touch design is not written as nineteen separate handlers. It is written as a table: which channels are enabled, what threshold applies to each, what baseline each channel settled on, and in what order the scan proceeds. That table lives in flash, is read at start-up, and is updated in RAM as the baselines drift.

For a reader this is the most informative structure in the whole image, because it states the design’s physical layout in numbers. The number of entries says how many electrodes the product has. The threshold column says how sensitive the design needed to be, which correlates with overlay thickness and electrode size. The baseline column says what the raw counts look like on a real board, which is the single most useful figure for anyone rebuilding the product.

A table with twelve entries read out of a firmware that was written for a hundred-pin board tells you either that only twelve electrodes were used, or that the build was retargeted. The distinction is usually visible from whether the unused entries are absent or present-and-disabled.

The converter sequence as a second fingerprint

The converter is configured with a channel sequence, and the sequence order is a design decision, not an accident. A design that reads a strain gauge, then a temperature sensor, then a battery voltage, will have those three channels in that order, because the sequence determines the settle time between conversions.

Reading the sequence gives the same information the touch table gives: how many analogue inputs the product actually uses, and in what priority. Combined with the touch table it produces a complete inventory of the product’s sensing surface, which for many customers is more valuable than the code.

What happens when a larger build is restored smaller

Restoring a hundred-pin image onto a sixty-four-pin part produces a specific failure signature, and it is worth recognising because it looks like a firmware bug rather than a package mismatch.

Start-up completes. The touch scan runs and returns values. The converter runs and returns values. But the channels above the package’s limit return either the last value latched or a constant, because the input is not connected to anything. The firmware has no way to know: from its point of view the conversion completed successfully.

The result is a device that appears to work and reports a fixed reading for the inputs that do not exist. On a touch panel this shows up as a key that is always pressed or always released; on a sensor input it shows up as a channel stuck at full scale or at zero.

Reading order for this package

1. Vector table: confirm base address, byte order, and that the image is complete.
2. Clock configuration: establish the operating frequency, because every timing constant depends on it.
3. Port configuration: collect the set of port bits and function selects written at start-up, which states the package the build expected.
4. Touch table: count entries and read thresholds and baselines.
5. Converter sequence: count channels and note the order.
6. Everything else.

Steps three to five answer the package question from three independent directions, and they take less time than reading the main loop.

What the deliverable contains

The return set is the code flash image at 256 KB, the data flash separately, the configuration words, the identification words as read, a disassembly with the vector table resolved, and the extracted tables: touch channels with thresholds and baselines, and the converter sequence.

Those extracted tables are usually the part of the report a customer reads first, because they describe the product rather than the program.

The step down from eighty pins, and what it costs in general-purpose I/O rather than channels, is in R7FA2L1AB3CFN program recovery. The hundred-pin member and its field-by-field decoding are in R7FA2L1AB3CFP software extraction. A full treatment of the touch unit itself is at R7FA2L1A93CFM firmware recovery.

FAQ

Does the silicon have fewer touch channels on this package? The block is the same. What changes is how many of its inputs are bonded to pins.

Why does an unbonded converter channel not report an error? The conversion completes on whatever the input network presents. With no pin, that is not a signal, and the result is a constant rather than a fault.

Can a sixty-four-pin design be identified without the code? Sometimes, from the board. From the image it is straightforward, because the channel tables state it.

Conclusion

Sixty-four pins is where this group stops being a slightly smaller hundred-pin part and starts being a different product. The touch and converter front ends are limited by the package, and the firmware records those limits in tables that are easy to find and easy to read. Locating them answers the package question, the sensor-count question and, often, the customer’s actual question about what the device measured.

Comments are closed.