Posts Tagged ‘mcu source program recovery’
Recover MCU R5F562T6DDFF Program: Every Delay Loop Is a Statement About a Clock You Cannot Read
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
| stage | options on this group | decided by |
|---|---|---|
| primary source | external crystal, or the high-speed on-chip oscillator | the initialisation sequence |
| secondary source | a low-speed on-chip oscillator, and a sub-clock input for timekeeping | the peripheral configuration |
| multiplication | a PLL with a programmable divider and multiplier | two register writes in the startup path |
| distribution | separate dividers for core, bus and peripherals | the same startup path |
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.
Recover MCU R5F562TABDFF Program: The Bundle Is the Deliverable, and Half of It Is Configuration
The word program is doing specific work in a request. It does not mean the code, and it does not mean the file. It means something a production line can act on: put this into a blank device and get a unit that behaves like the one that came out of it.
On an RX62T that requires four artefacts, and only one of them is the array. The other three live in the same flash or in the customer’s head, and the failure that follows from omitting them is not a failed burn — it is a unit that works, and then behaves differently from the original under a condition nobody tested.
R5F562TABDFF#V3 is one of the larger-memory order codes in the group, QFP-type package, with a version suffix that identifies a shipping configuration. Its peripheral set is the motor-control one: two twelve-bit converter units, a six-channel timer, a thirty-two-bit general timer, and the output-enable logic that makes an inverter safe when the core stops.
What the top of the map contains
| region | what it holds | why a rebuild needs it |
|---|---|---|
| reset vector | the initial program counter | without it the device does nothing |
| exception vectors | handlers for faults and interrupts | without them the first fault becomes a hang |
| option-setting memory | watchdog, protection, reset behaviour, clock supervision | without it the unit behaves differently under fault |
| the array proper | code and constants | the part customers think of as “the program” |
The third row is the one that gets skipped, and it is the one that decides whether a rebuilt unit survives a brown-out, a stuck loop or a watchdog reset the way the original did. It sits in the same flash, immediately below the vectors, and a full read returns it as ordinary data — which is precisely why it gets mistaken for part of the code and never examined.
What the configuration actually changes
Three fields do most of the work, and each has a symptom that appears weeks after delivery.
The watchdog configuration decides whether a watchdog runs, how long its period is, and whether it can be disabled by software. A rebuild with the watchdog off runs perfectly on a bench and fails in the field, because the original design’s fault recovery depended on the reset happening. This is the most common omission and the hardest to argue about after the fact.
The protection setting decides whether the programming interface will read the device at all. Copying it into a replacement reproduces the original’s behaviour exactly, including the part where the next recovery is harder. Leaving it off makes the replacement easier to service and different from the original. Both choices are defensible; making it by accident is not.
The reset and supervision settings decide how the device behaves while the supply is rising and falling. A design with a slow supply ramp and a conservative supervision threshold will start reliably; the same code on a rebuilt unit with a different threshold will occasionally not start at all, and the symptom will look like a firmware bug for as long as it takes somebody to compare the configuration bytes.
Why reading it first saves a session
There is a practical reason to read the option area before the array, beyond completeness.
It predicts whether the array will answer. A device whose protection state is set will complete the handshake and return a uniform value; knowing that in advance is the difference between diagnosing a protected device in a minute and diagnosing a dead fixture over an hour.
It also reveals the boot configuration. Some designs start into a loader rather than into the application, and a listing that assumes the reset vector points at the application will analyse the wrong code first.
And it records the clock supervision settings, which constrain the code: a design that supervises its oscillator will contain a startup sequence that waits for stability, and that sequence is a landmark for finding the beginning of the application.
What a burnable bundle contains
Four items, each of which answers a question the others cannot.
The full image with addresses, in the format the customer’s programmer accepts, including the top-of-map regions rather than stopping below them.
A configuration summary: protection state, watchdog behaviour, reset pin function, supervision thresholds — in words, with the raw values alongside so that a disagreement can be settled.
A clock statement. This is not in the flash at all: the design assumes a crystal or an internal oscillator at a specific frequency, and the code’s timing constants are meaningless without it. Two lines of text prevent a whole class of after-sales argument.
And a map: which address ranges are code, which are constant tables, which are the vectors, and which are configuration. A customer who receives four files without a map will eventually burn the wrong one into the wrong region.
The failure that follows from omitting the configuration
It is worth describing in one paragraph, because it is the reason this page exists.
A unit is rebuilt from a correct image with default configuration. It boots, it runs, it drives the motor, and it passes the functional test. Three months later, in a cabinet where the supply dips on a contactor closure, the original units reset and recover while the rebuilt ones latch into a state that requires a power cycle. Nothing in the code is different. The difference is a supervision threshold nobody copied, and finding it takes a comparison of two configuration dumps that nobody kept.
That is the entire argument for treating the option area as part of the program rather than as an implementation detail.
For the flash read that produces the array in the first place, R5F562T6EDFF flash covers the protection matrix. For a data store that also lives in the same flash, R5F562TAEDFF EEPROM explains the emulation scheme. And for the clock question that the bundle has to state explicitly, R5F562T6DDFF program takes it apart.
FAQ
Is the option area part of the hex file? On a full read, yes, as ordinary data. It is still a separate concept and it should be reported separately, because it configures behaviour rather than containing it.
Can a rebuild use default configuration? It can, and it will behave like a different product. Whether that matters depends on what the original was protecting against.
Does copying the protection setting make the replacement harder to service? Yes, and deliberately. That is why the choice should be the customer’s rather than the supplier’s default.
The short version
A program is four artefacts. Read the top of the map before the array, report the configuration in words as well as bytes, state the clock the code assumes, and provide a map so nobody burns the wrong region. The array gets a unit to boot; the other three get it to behave like the one it replaced.