Scope: one part, two documents
This article covers the clock system of the ATxmega32A4U as described in the A4U datasheet and the XMEGA AU manual. The datasheet addresses the ATxmega128A4U, ATxmega64A4U, ATxmega32A4U and ATxmega16A4U, and lists the ATxmega32A4U-AU with 32 KB of flash plus a 4 KB boot section, 1 KB of EEPROM and 4 KB of SRAM. Everything below is pinned to that part and those two documents. It is not a description of every XMEGA device, and bit-level details should be read from the document revision actually in use rather than from a summary.
The 2014 framing, and what it left open
Embedded Lab’s December 2014 article by Shawon Shahryiar introduced the subject to hobbyist readers with a contrast that is still widely repeated: “clocks are not set by fuse settings unlike traditional Mega AVRs, they are controlled by software and the outputs from these sources can be multiplied using the internal Phase Locked-Loop (PLL).” As a statement about where configuration lives, that is a fair description of the architectural change from classic megaAVR parts. It is not a guarantee of accuracy, startup time or usable frequency, and it was written as an introductory secondary account in 2014, not as a characterization of any particular board.
What the framing tends to obscure is that software configuration is not unrestricted configuration. The settings live in registers that the device deliberately makes hard to change by accident, and the sequence used to change them is specified in instruction cycles, not milliseconds.
Clock registers can be locked before you touch them
Both documents describe an optional lock for features regarded as safety-critical. The manual states that “it is possible to lock the I/O register related to the clock system”, and that while the lock is enabled “all related I/O registers are locked and they can not be written from the application software.” The lock registers are not a loophole: “The lock registers themselves are protected by the configuration change protection mechanism.” (XMEGA AU manual)
The practical consequence is that a write can be correct in source and still have no effect. A firmware routine that selects a new system clock and then behaves as though the change succeeded has no way of knowing whether the register accepted the value unless it reads the register back. Silent rejection is the failure mode to design against, and it is indistinguishable from a source that never started.
The protected write window is four instruction cycles
Protected registers are changed through the configuration change protection mechanism. The manual states that modifications are “only possible after the CPU writes a signature to the CCP register”, and that there are “two modes of operation” covering protected registers and protected instructions. For registers, the sequence is two writes: the application writes the enabling signature to the CCP register, then “within four instruction cycles, the application code must write the appropriate data to the protected register.” (XMEGA AU manual)
That window is the detail most likely to be lost when the operation is wrapped in ordinary C. Four instruction cycles is a property of the executed instruction stream, not of wall-clock time, and it does not expand because the surrounding code is slow. As a derivation, if the CPU is running from the 2 MHz internal oscillator that the manual’s calibration registers refer to, four cycles correspond to 2 microseconds (CALCULATIONS: 4 / 2,000,000 Hz). A function call, a loop, a delay inserted to “let the setting settle”, or an interrupt taken between the two writes all consume from the same budget. Once the window closes, the data write is not a protected write and the register keeps its previous value.
The signature write and the data write must therefore be adjacent in the executed stream, with interrupts on the intervening cycles treated as part of the design. No code is given and no timing was measured.
Enable and readiness come before selection
The protection mechanism answers one question only: whether software is permitted to modify a protected register. It does not wait for anything. A completed protected write says nothing about whether the source just selected is running, settled, or within the tolerance the application needs.
The order that follows is: start or enable the intended source, establish that it is ready, and only then perform the protected selection that makes it the system clock. The specific enable and ready-status bits are defined in the clock system chapter of the manual and are not restated here, because they differ by source and must be taken from the revision in use. What can be stated from the protection text is the asymmetry: the selection step is guarded and immediate, while readiness is a separate condition that guarding does not create.
A readiness poll placed between the signature and the data write would consume the window itself, so the poll cannot be folded into the protected step; it belongs before it.
DFLL calibration belongs to the internal 2 MHz source
The manual’s calibration register description scopes the digital frequency-locked loop narrowly: the byte “contains the oscillator calibration value for the internal 2MHz oscillator”, calibration is carried out “during production testing of the device”, and during reset the value is “automatically loaded into calibration register” for that oscillator. The stored value is therefore factory data for that specific internal oscillator, not a user correction for an arbitrary external clock. (XMEGA AU manual)
PLL and reference choices depend on the exact source
PLL multiplication is the capability the 2014 article highlighted, and it is real, but the supplied manual excerpt does not enumerate which sources may serve as a PLL reference or what multiplier range applies to each. Those are clock-chapter properties that vary with source selection. An external crystal, an internal RC oscillator and an already-derived clock do not share accuracy, startup behaviour or usable reference range, so a multiplier setting validated against one reference is not transferable to another without checking the chapter for that combination.
Configuration is programmable, but the legal configurations are constrained by source, reference path and device, and the constraints are documented rather than implied by the existence of a register field.
What this article does not establish
No initialization code is provided, no clock switch has been compiled or executed, and no frequency, startup time, stability or power figure is claimed for any configuration. The 2014 write-up is cited as historical context for how the family was introduced to hobbyists, not as evidence of universal behaviour. Nothing here asserts that fuse settings are irrelevant on every XMEGA part, or that software configuration removes the need to characterize a source for a specific application. Readers evaluating a design should treat the datasheet and manual for the exact ordering code as the authority and verify each step on hardware.
Related material on this site includes a discussion of externally clocking and overclocking AVR MCUs and a low-power LCD clock built on an AVR128DA48. Both illustrate the same dependency: the source and its configuration determine what the rest of the system can rely on.
