There is a class of question a recovered image answers perfectly and a class it cannot answer at all, and clock frequency is in the second class. The image says which oscillator the code selects, how it programs the PLL, and how long it waits for stability. It does not say what the crystal on the board is, because that component is not in the flash.

This matters more on a hundred-megahertz motor-control part than on a small controller, because the ratio between the crystal and the core clock is large and programmable, and because a design that gets its timing wrong does not fail cleanly — it runs, and the motor turns at the wrong speed, and the current loop oscillates at a frequency nobody chose.

R5F562T6DDFF#V1 is an RX62T group device: thirty-two-bit core with an FPU, two twelve-bit converter units, a six-channel motor timer, and an output-enable block that can shut the inverter down in hardware when the core stops responding.

The clock tree, and what the code decides

Four fields, three register writes, and one physical component that is not in the image. That is the whole problem in one line.

The code will tell you which source it selected and what it programmed the PLL to. It will not tell you the crystal’s frequency, because the code does not know it either — the divider and multiplier are integer values chosen by whoever wrote the design, and the resulting frequency is a product of those values and a number that exists only on the schematic.

Reconstructing the tree

The startup sequence is short and stereotyped, and reading it in order produces the tree.

First comes the oscillator selection: which source is enabled, and whether the design waits for a stability flag before proceeding. A design that waits is a design with a crystal, because an on-chip oscillator does not need to be waited for. That single observation separates the two cases on most units.

Second comes the PLL programming: a divider on the input and a multiplier, written as plain integers. Those integers are the only hard evidence about the external component.

Third comes the distribution: the core divider, the bus divider and the peripheral divider. These are what turn one clock into three, and they explain why a peripheral register value in the code looks wrong when divided by the core frequency instead of the peripheral one.

Fourth comes the peripheral configuration, which on this part is dominated by timers. A motor-control design configures a carrier frequency, a dead time, and one or two converter trigger points. Every one of those numbers was chosen as a number of clock cycles, and every one of them is meaningless without the clock.

Where the timing constants hide

Five places, and a recovery that does not annotate them has delivered a program that nobody can safely modify.

Serial divisors. A baud rate register value encodes the ratio between the peripheral clock and the bit rate. Two designs at different clocks produce different divisors for the same baud rate, which means the divisor is evidence, not noise.

Converter timing. A sampling time expressed in cycles produces a sample rate in microseconds only once the clock is known. On a current-sense input, that number is a stability margin.

Pulse-width periods. A motor timer’s period register sets the carrier frequency. A customer who changes it without knowing the clock will either hear the motor or destroy the bridge.

Delay loops. A counted loop used for a microsecond-scale wait is calibrated in cycles, and it is the classic place where a rebuild at a different clock runs at the wrong speed.

Watchdog periods. The watchdog configuration is in the option bytes but the timeout is a clock count, and a watchdog that fires at the wrong interval under load looks exactly like a firmware bug.

Why the same image on another board runs wrong

A replacement built from a recovered image is only a replacement if the board provides the same clock. On a product with several hardware revisions this is a real risk, because a later revision may have replaced a crystal with the on-chip oscillator to save a component, and the code was changed to match.

The failure mode is specific and it is not a crash. The unit boots, runs, and behaves plausibly, and then the serial protocol it uses to talk to the rest of the machine produces framing errors at some temperatures, or the current loop becomes unstable above a certain load. Those symptoms are attributed to the recovery, and the actual cause is a clock statement that was never written down.

What belongs in the delivery

Three items, and each one closes a different hole.

The reconstructed tree: source, PLL settings, and the resulting core, bus and peripheral frequencies, stated as numbers.

The assumption about the external component, stated explicitly as an assumption where it could not be verified from the part.

And a list of the annotated timing constants, in the listing, at the places where they appear — because a note in the covering letter is read once, and a comment next to the instruction is read every time somebody changes it.

For the rebuild that has to reproduce these constants exactly, R5F562T6BDFF software covers the project reconstruction. For the configuration bytes that set the watchdog period, R5F562TABDFF program deals with the option area. And for a device where the clock is chosen at order time rather than in software, PIC16C57C firmware is the opposite extreme.

FAQ

Can the crystal frequency be determined from the image alone? No. The image contains integer divider and multiplier values, and the product of those with an unknown input is an unknown output.

Does an on-chip oscillator remove the problem? It removes the external component, not the problem. The code still assumes a frequency, and the option bytes may select a different one from the one the code expects.

Is a timing error always visible? Rarely. It usually appears as a marginal behaviour under load or temperature, which is why the annotation matters more than the diagnosis.

The short version

The image states the clock’s shape and never its size. Read the startup sequence to recover the tree, treat the external component as an assumption, annotate every constant that depends on it, and say in the delivery which frequencies the code assumes. That paragraph is the cheapest insurance in the whole engagement.

Comments are closed.