An image read without knowing its clock is a list of instructions with no durations. Delay loops cannot be checked, serial rates cannot be computed, and the converter timing looks arbitrary.

Every one of those quantities descends from a single configuration: which oscillator the core runs from, what the phase-locked loop multiplies it to, and how the result is divided before it reaches the peripherals. That configuration is written in the first few hundred bytes of almost every firmware, and reading it converts the rest of the disassembly from numbers into behaviour.

Where the clock comes from

A design that needs an accurate serial rate uses the external crystal, because an internal oscillator is specified in percent rather than in parts per million. A design that only needs to be approximately right uses the internal source and saves two pins and two components.

Which was chosen appears in the initialisation code as a write selecting the system clock source, and again as an enable for the oscillator that was chosen. Two writes, minutes apart in reading, seconds apart in execution.

The bring-up sequence has a fixed order

Oscillators cannot be switched instantly. The sequence a careful firmware follows is always the same shape:

1. Enable the new source and wait for it to become stable.
2. Set the dividers for the domains that will use it.
3. Switch the system clock to the new source.
4. Disable the source that is no longer needed.

Step one contains a wait loop, and that loop has a timeout. The timeout count is a constant in the image, and it is calibrated against the slowest oscillator the design expects — usually the low-speed one, whose start-up is measured in seconds rather than microseconds.

Finding that loop is a reliable landmark. It sits in the clock configuration, it is called exactly once at start-up, and it is followed immediately by the switch.

The baud divisor is a measurement of the clock

Serial rates are generated by dividing the peripheral clock, so a baud register holds a divisor that is a function of the clock frequency. That makes the register a measurement in disguise: read the divisor, assume the baud rate, and the clock falls out.

This is the cross-check that resolves most disputes about which clock a design actually ran at, and it works in both directions: a divisor that does not correspond to any plausible clock means the image came from a different build than assumed, or the peripheral is clocked from a different domain than the core.

For a restoration the consequence is direct. An image restored onto a part with a different crystal, or with the crystal absent, produces a device whose serial communication is wrong by exactly the ratio of the two frequencies — and which otherwise works.

What the low-power modes cost

This family has several reduced-power states, and they differ in what survives. The shallow one stops the core. The deeper ones stop clocks to whole domains. The deepest stops nearly everything and requires a full start-up sequence to leave.

The fourth row is the interesting one on this part. A peripheral can be left running while the core sleeps and can wake it on a condition — a conversion above a threshold, a touch detection, a byte arriving on a serial port. That arrangement is why the part appears in products that wait a long time and react quickly.

The wake path is where the application hides

In a product built around standby, the code that matters is not the main loop. It is the short handler that runs after a wake, does one thing, and goes back to sleep. Reading a firmware of this shape from the reset vector forward means reading a great deal of initialisation followed by an instruction that stops the core, and nothing else.

The productive route is the reverse: find the wake source configuration, then the handler it triggers, then the code that decides whether to do work or to sleep again. That path crosses the whole application in a few hundred bytes.

Reading the clock section

1. Find the oscillator enable and the wait-for-stable loop. That establishes which source exists.
2. Read the divider registers set immediately afterwards. They give the domain frequencies.
3. Read the loop multiplier if one is configured, and the source it multiplies.
4. Find a serial divisor and compute the implied rate as a cross-check.
5. Find the sleep instruction and the wake configuration, and note which peripheral is armed.

Steps one to four take under an hour and they make every later timing question answerable.

What the deliverable contains

The return set is the code flash image, the data flash separately, the configuration words, the identification words as read, a disassembly with the clock configuration annotated, a table of the resulting domain frequencies, and a note stating which oscillator the design depends on.

That last note decides whether an image can be moved. A design that assumes an external crystal will not keep time on a board that does not have one, and the failure looks like a firmware defect rather than a missing component.

The array size that limits how much of this firmware fits is in R7FA2L1A93CFP binary recovery. The supply range that constrains which oscillator can be used at the extremes is in R7FA2L1A92DFM program recovery, and the ordering code that names the part in R7FA2L1AB3CFP software extraction.

FAQ

Can the clock be determined from the image alone? Yes, from the source selection, the dividers and the loop multiplier, with the serial divisor as an independent check.

Why does a restored image run at the wrong speed? Because the oscillator the build assumed is not the oscillator the board has. The code is correct; the hardware is not what it expects.

Does standby erase RAM? No, but it does stop everything else. The wake path has to restore the clock before any peripheral is used.

Conclusion

A firmware’s timing is one decision propagated through a dozen registers. Read the oscillator selection, the dividers and the loop multiplier first, confirm with a serial divisor, and the rest of the image acquires durations. Then find the sleep instruction, because on a low-power product that is where the application actually starts.

Comments are closed.