R7FA2L1A92DFL: The Configuration Words at the Bottom of the Array
July 5th, 2015 | 
Author: Not everything in the code flash is code. At fixed addresses near the start of the array there are a handful of words that the hardware reads during reset, before the first instruction of the application executes, and uses to configure behaviour the core cannot configure for itself.
They are ordinary flash contents, programmed the same way as everything else, and erased the same way. That is what makes them dangerous: a routine erase that was meant to clear the application can silently change how the device starts.
Where they are and what they are called
The area is called option-setting memory, and it sits at fixed addresses in the code flash. It is not a separate array and it does not need a special command; it is simply a region whose contents mean something to the reset logic rather than to the program.
| word group | what it configures | consequence if changed |
|---|---|---|
| watchdog settings | whether the independent watchdog runs from reset, and its timeout | a device that resets in a loop, or one with no protection |
| watchdog window | the allowed refresh window | resets that appear random in timing |
| voltage detection | thresholds at which the part warns or resets | behaviour on a sagging supply |
| oscillator configuration | start-up behaviour of the internal high-speed source | a device that starts slowly, or not at all |
| start-up options | which interfaces are enabled out of reset | a debug port that never appears |
The first two rows account for the failure that reaches a bench most often. The independent watchdog is not disabled by a reset; whether it runs is a property of these words. Where they have been erased, the default applies, and the default is frequently «enabled».
Why they are flash rather than fuses
A fuse is set once and cannot be revisited cheaply. These are flash, which means they can be changed in the field, which means a firmware update can correct a configuration mistake — a real advantage for a product that ships in volume.
The cost of that choice is that they are vulnerable to the same operations as everything else. A whole-array erase removes them. A partial erase that happens to cover their region removes them. And an image restored from a different product may carry a different set of them, which silently changes the rules the device starts under.
| property | fuse-based configuration | option-setting memory |
|---|---|---|
| can be changed after production | no | yes |
| erased by a whole-array erase | no | yes |
| travels with an image | no | yes, if the image covers that address |
| can be lost by a partial write | no | yes |
The third row is the one with consequences for a recovery. Where a delivered image includes the configuration region, restoring it also restores the configuration — which is usually correct and occasionally catastrophic, if the destination board has different hardware.
The failure that looks like a brick
The classic presentation is a device that was erased, reprogrammed with a correct application image, and now resets every few hundred milliseconds without executing anything useful.
Nothing is wrong with the application. The configuration words were erased, the independent watchdog took its default state, and the application does not refresh it because in the original build it was not running.
| observation | what it suggests |
|---|---|
| resets at a fixed short interval | watchdog running, not refreshed |
| resets at an irregular interval | watchdog window, or a voltage threshold |
| runs for a while then resets | watchdog timeout longer than first thought |
| never starts | oscillator configuration, or a start-up option |
The first row is diagnostic enough that it is worth knowing before shipping a unit back. A device that resets on a stopwatch is not a device with a firmware bug; it is a device whose start-up configuration no longer matches what the firmware expects.
What the report should state
The configuration words should be delivered in two forms: as bytes in the image, and as decoded values in the report.
The bytes matter because they are part of a faithful copy. The decoded values matter because they are the only thing that tells a customer whether their production image is complete. A customer who has been flashing only the application region has been relying on whatever configuration was in the part, and that reliance is invisible until it fails.
| item | why it belongs in the report |
|---|---|
| the words as read | a faithful copy is what a recovery is for |
| the decoded watchdog state | answers «will this reset on its own» |
| the voltage thresholds | explains behaviour on a weak supply |
| whether the delivered image covers the region | tells the customer whether their fixture is complete |
The fourth item is the one that changes behaviour, because it turns an assumption into a statement.
Reading them out of an image
- Locate the region by its fixed address. Its position is a property of the part, not of the design.
- Decode the watchdog fields first, because they determine whether the device can run at all.
- Decode the voltage and oscillator fields next.
- Check whether the values look plausible or erased. All-ones in this region is not a valid configuration; it is a missing one.
- Note in the report whether the rest of the image assumes these values or overrides them at run time.
Step five is a distinction worth making. Some firmware reconfigures the watchdog in software immediately at start-up, which makes the option-setting value relevant only for the interval between reset and that code. Others rely on it entirely.
What the deliverable contains
The return set is the code flash image including the configuration region, the data flash separately, the configuration words decoded, the identification words as read, a disassembly with the vector table resolved, and a statement of what the device does at reset given those words.
A second page on this ordering code, written from the general extraction angle, is at R7FA2L1A92DFL binary extraction. The address-range restriction that may cover this region is covered in R7FA2L1AB2DFL flash recovery, and the boot path those start-up options affect in R7FA2L1AB2DFM software recovery.
FAQ
Are these words part of the program? No. They are flash contents read by hardware at reset, not instructions.
Can they be erased by accident? Yes. Any operation covering their addresses removes them, including a whole-array erase.
Does a correct application image restore them? Only if the image includes that address range. Many production images do not.
Conclusion
A handful of words at fixed addresses decide how the part behaves before any code runs, and they are as easy to erase as anything else in the array. Reading them is trivial; decoding them answers whether a device will reset itself in a loop; and stating in the report whether the delivered image covers them turns a silent assumption into something the customer can check.
Posted in Break IC