Identify the factory calibration store
Historical AVR053 describes factory calibration of internal RC oscillators in tinyAVR and megaAVR devices. In its example, a calibration byte is retained in the device’s signature row. This information belongs to the oscillator’s factory-trim context: manufacturing variation can make the stored byte differ between individual devices. Its presence is therefore not, by itself, evidence that a customer loaded an application. A memory description that calls every retained byte customer firmware would lose the manufacturer’s separate explanation of this per-device calibration information.
The distinction becomes clearer when the note discusses devices with more than one RC oscillator. The relevant factory data belongs to the oscillator being described, rather than representing a general program image shared by every product carrying an AVR name. Device identity and oscillator identity therefore matter to the meaning of calibration data. This article uses that historical explanation without reading any offered unit. It identifies why factory trim information has a different purpose from application instructions, not whether a particular unit contains customer code or which calibration byte it presently holds.
Distinguish stored calibration from active trim
The stored calibration byte and OSCCAL have different roles. AVR053 describes OSCCAL as the register used to trim the tunable internal RC oscillator. The signature-row value is retained factory data; the operating register is the control through which trim is applied. Knowing that the factory value exists does not establish which value is currently active. Likewise, a statement about an active trim control would not automatically describe the original factory byte. Treating both as one undifferentiated calibration state hides the relationship between storage and use.
This distinction also explains why the word calibrated needs context. It can refer to the factory process that established a retained value, or to the trim presently applied in operation. The note’s architecture connects those subjects without making them identical. A description of customer application code answers another question again: what instructions the application contains. The presence of an operating trim register neither proves that application code is original nor reveals its contents. Here the useful technical account is the separate data source and active control, without a register setting, a readout procedure or a new frequency measurement.
Separate oscillator calibration from clock scaling
AVR053 defines base frequency before prescaling and discusses system-clock scaling separately. Prescaling changes the clock delivered through the scaling mechanism without necessarily changing the oscillator’s factory calibration data. Consequently, a changed CPU-clock description cannot be treated as direct proof that the oscillator’s calibration byte was altered. The oscillator’s generation of a base frequency and the later division of that frequency are distinct parts of the clock explanation. Combining them into one frequency field obscures where a reported change belongs.
Clock-source selection is another separate question. A description of an internal RC oscillator does not establish that it is the source currently used by a particular application. The source choice, base oscillator behaviour, scaling and active trim can therefore contribute different information to a clock record. None should be inferred merely from a familiar nominal CPU-frequency label. This is a functional distinction, without a fuse setting or clock-configuration instruction. It also avoids confusing this topic with external crystal or TCXO identification: an internal oscillator’s stored trim and clock scaling are different mechanisms from the interfaces of those timing products.
Keep startup loading device-specific
The historical note qualifies startup loading by device and oscillator context. It describes common cases in which a default calibration value is automatically copied to OSCCAL, alongside cases needing application handling for a different oscillator choice. That distinction prevents a universal assertion that every AVR always starts with the same relationship between its retained byte and active register. Automatic loading is a documented behaviour under its stated context, rather than a conclusion that follows from the broad family name or the mere existence of a signature row.
Voltage and temperature also remain part of the oscillator explanation. AVR053 notes that internal RC frequency depends on those operating conditions and directs exact behaviour to the individual device documentation. A factory-calibration description should consequently retain its context instead of becoming an unconditional frequency-accuracy promise. For a seller’s technical description, the useful result is to distinguish factory data, active trim, source/scaling and startup behaviour. It does not prescribe recalibration or establish the clock of offered material. The stored constants and customer application code remain separate subjects throughout that explanation.
Sources and further reading
Historical Atmel-2555H AVR053, physical pages 3–4, supports the bounded factory-data, trim, scaling and startup distinctions. No accuracy value, fuse/register setting, calibration algorithm or result for offered devices is supplied.