The EFM32 Jade Gecko MCUs are the world’s most energyfriendly microcontrollers.
EFM32JG1 features a powerful 32-bit ARM® Cortex-M3 and a wide selection of peripherals, including a unique cryptographic hardware engine supporting AES, ECC, and
SHA. These features, combined with ultra-low current active mode and short wake-up
time from energy-saving modes, make EFM32JG1 microcontrollers well suited for any
battery-powered application, as well as other systems requiring high performance and
low-energy consumption.
Example applications:
• IoT devices and sensors
• Health and fitness
• Smart accessories
Core / Memory
ARM Cortex
Flash Program
Memory
TM
M3 processor
RAM Memory
Memory
Protection Unit
Debug InterfaceDMA Controller
• Home automation and security
• Industrial and factory automation
Clock Management
High Frequency
Crystal
Oscillator
Low Frequency
RC Oscillator
Low Frequency
Crystal
Oscillator
High Frequency
Auxiliary High
Frequency RC
Frequency RC
ENERGY FRIENDLY FEATURES
• ARM Cortex-M3 at 40 MHz
• Ultra low energy operation:
• 2.1 μA EM3 Stop current (CRYOTIMER
running with state/RAM retention)
• 2.5 μA EM2 DeepSleep current (RTCC
running with state and RAM retention)
• 63 μA/MHz in Energy Mode 0 (EM0)
• Hardware cryptographic engine supports
AES, ECC, and SHA
This information applies to a product under development. Its characteristics and specifications are subject to change without notice.
TM
2
C
I/O PortsTimers and Triggers
External Interrupts
General Purpose I/O
Pin Reset
Pin Wakeup
EM1 - Sleep
Timer/CounterLow Energy Timer
Pulse Counter
Watchdog Timer
EM2 – Deep Sleep
Real Time Counter
and Calendar
CRYOTIMER
EM3 - Stop
Analog Interfaces
ADC
Analog Comparator
IDAC
EM4 - Hibernate
Other
CRYPTO
CRC
EM4 - Shutoff
EFM32JG1 Reference Manual
About This Document
1. About This Document
1.1 Introduction
This document contains reference material for the EFM32 Jade Gecko devices. All modules and peripherals in the EFM32 Jade Gecko
devices are described in general terms. Not all modules are present in all devices and the feature set for each device might vary. Such
differences, including pinout, are covered in the device data sheets.
Register names are given with a module name prefix followed by the short register name:
TIMERn_CTRL - Control Register
The "n" denotes the module number for modules which can exist in more than one instance.
Some registers are grouped which leads to a group name following the module prefix:
GPIO_Px_DOUT - Port Data Out Register
The "x" denotes the different ports.
Bit Fields
Registers contain one or more bit fields which can be 1 to 32 bits wide. Bit fields wider than 1 bit are given with start (x) and stop (y) bit
[y:x].
Bit fields containing more than one bit are unsigned integers unless otherwise is specified.
Unspecified bit field settings must not be used, as this may lead to unpredictable behaviour.
Address
The address for each register can be found by adding the base address of the module found in the Memory Map (see Figure 4.2 Sys-
tem Address Space with Core and Code Space Listing on page 15), and the offset address for the register (found in module Register
Map).
Access Type
The register access types used in the register descriptions are explained in Table 1.1 Register Access Types on page 2.
Table 1.1. Register Access Types
Access TypeDescription
RRead only. Writes are ignored
RWReadable and writable
RW1Readable and writable. Only writes to 1 have effect
(R)W1Sometimes readable. Only writes to 1 have effect. Currently only
used for IFC registers (see 3.3.1.2 IFC Read-clear Operation)
W1Read value undefined. Only writes to 1 have effect
WWrite only. Read value undefined.
RWHReadable, writable, and updated by hardware
RW(nB), RWH(nB), etc."(nB)" suffix indicates that register explicitly does not support pe-
ripheral bit set or clear (see 4.2.2 Peripheral Bit Set and Clear)
RW(a), R(a), etc."(a)" suffix indicates that register has actionable reads (see
5.3.6 Debugger reads of actionable registers)
Number format
0x prefix is used for hexadecimal numbers
0b prefix is used for binary numbers
Numbers without prefix are in decimal representation.
Reserved
Registers and bit fields marked with reserved are reserved for future use. These should be written to 0 unless otherwise stated in the
Register Description. Reserved bits might be read as 1 in future devices.
Registers denoted with X have unknown value out of reset and need to be initialized before use. Note that read-modify-write operations
on these registers before they are initialized results in undefined register values.
Pin Connections
Pin connections are given with a module prefix followed by a short pin name:
CMU_CLKOUT1 (Clock management unit, clock output pin number 1)
The location for the pin names given in the module documentation can be found in the device-specific datasheet.
1.3 Related Documentation
Further documentation on the EFM32 Jade Gecko devices and the ARM Cortex-M3 can be found at the Silicon Labs and ARM web
pages:
The EFM32 Jade Gecko is a highly integrated, configurable and low power MCU with a complete set of
peripherals.
Why?
EFM32 Jade Gecko features an Cortex-M3 core, a
unique cryptographic hardware engine supporting
AES, ECC, and SHA, ultra-low current active mode,
and short wake-up time from energy-saving modes.
How?
EFM32 Jade Gecko microcontrollers are well suited
for any batter-powered application, as well as other
systems requiring high performance and low-energy
consumption
2.1 Introduction
The EFM32 MCUs are the world’s most energy friendly microcontrollers. With a unique combination of the powerful 32-bit ARM CortexM3, innovative low energy techniques, short wake-up time from energy saving modes, and a wide selection of peripherals, the EFM32
Jade Gecko microcontroller is well suited for any battery operated application as well as other systems requiring high performance and
low-energy consumption.
• Ultra efficient Power-on Reset and Brown-Out Detector
• Debug Interface
• 4-pin Joint Test Action Group (JTAG) interface
• 2-pin serial-wire debug (SWD) interface
2.4 Oscillators and Clocks
EFM32 Jade Gecko has six different oscillators integrated, as shown in Table 2.1 EFM32 Jade Gecko Oscillators on page 7
Table 2.1. EFM32 Jade Gecko Oscillators
OscillatorFrequencyOptional?External
Description
components
HFXO38 MHz - 40 MHzNoCrystalHigh accuracy, low jitter high frequency crystal oscillator. Tun-
able crystal loading capacitors are fully integrated.
HFRCO1 MHz - 38 MHzNo-Medium accuracy RC oscillator, typically used for timing dur-
ing startup of the HFXO or if a precise oscillator is not required.
AUXHFRCO1 MHz - 38 MHzNo-Medium accuracy RC oscillator, typically used as alternative
clock source for Analog to Digital Converter or Debug Trace.
LFRCO32768 HzNo-Medium accuracy frequency reference typically used for medi-
um accuracy RTCC timing.
LFXO32768 HzYesCrystalHigh accuracy frequency reference typically used for high ac-
curacy RTCC timing. Tunable crystal loading capacitors are
fully integrated.
ULFRCO1000 HzNo-Ultra low frequency oscillator typically used for the watchdog
timer.
The RC oscillators can be calibrated against either of the crystal oscillators in order to compensate for temperature and voltage supply
variations. Hardware support is included to measure the frequency of various oscillators against each other.
Oscillator and clock management is available through the Clock Management Unit (CMU), see section 10. CMU - Clock Management
Unit for details.
2.5 Hardware CRC Support
EFM32 Jade Gecko supports a configurable CRC generation:
• 8, 16, 24 or 32 bit CRC value
• Configurable polynomial and initialization value
• Optional inversion of CRC value over air
• Configurable CRC byte ordering
• Support for multiple CRC values calculated and verified per transmitted or received frame
EFM32 Jade Gecko has hardware support for AES encryption, decryption and authentication modes. These security operations can be
performed on data in RAM or any data buffer, without further CPU intervention. The key size is 128 bits.
AES modes of operations directly supported by the EFM32 Jade Gecko hardware are listed in Table 2.2 AES modes of operation with
hardware support on page 8. In addition to these modes, other modes can also be implemented by using combinations of modes.
For example, the CCM mode can be implemented using the CTR and CBC-MAC modes in combination.
Table 2.2. AES modes of operation with hardware support
EFM32 Jade Gecko includes multiple timers, as can be seen from Table 2.3 EFM32 Jade Gecko Timers Overview on page 9.
Table 2.3. EFM32 Jade Gecko Timers Overview
TimerNumber of instancesTypical clock sourceOverview
RTCC1Low frequency (LFXO or
LFRCO)
32 bit Real Time Counter and
Calendar, typically used to accurately time inactive periods
and enable wakeup on compare
match.
TIMER2High frequency (HFXO or
16 bit general purpose timer.
HFRCO)
Systick timer1High frequency (HFXO or
HFRCO)
32 bit systick timer integrated in
the Cortex-M3. Typically used
as an Operating System timer.
WDOG1Low frequency (LFXO, LFRCO
or ULFRCO)
Watch dog timer. Once enabled,
this module must be periodically
accessed. If not, this is considered an error and the EFM32
Jade Gecko is reset in order to
recover the system.
LETIMER1Low frequency (LFXO, LFRCO
or ULFRCO)
Low energy general purpose
timer.
Advanced interconnect features allows synchronization between timers. This includes:
• Start / stop any high frequency timer synchronized with the RTCC
• Trigger RSM state transitions based on compare timer compare match, for instance to provide clock cycle accuracy on frame transmit timing
The industry leading Cortex-M3 processor from
ARM is the CPU in the EFM32 Jade Gecko devices.
Why?
The ARM Cortex-M3 is designed for exceptionally
short response time, high code density, and high 32bit throughput while maintaining a strict cost and
power consumption budget.
How?
Combined with the ultra low energy peripherals
available in EFM32 Jade Gecko devices, the CortexM3 processor's Harvard architecture, 3 stage pipeline, single cycle instructions, Thumb-2 instruction
set support, and fast interrupt handling make it perfect for 8-bit, 16-bit, and 32-bit applications.
Instruction InterfaceData Interface
NVIC Interface
Memory Protection Unit
3.1 Introduction
The ARM Cortex-M3 32-bit RISC processor provides outstanding computational performance and exceptional system response to interrupts while meeting low cost requirements and low power consumption.
• Separate data and program memory buses (No memory bottleneck as in a single bus system)
• 3-stage pipeline
• Thumb-2 instruction set
• Enhanced levels of performance, energy efficiency, and code density
• Single cycle multiply and hardware divide instructions
• 32-bit multiplication in a single cycle
• Signed and unsigned divide operations between 2 and 12 cycles
• Atomic bit manipulation with bit banding
• Direct access to single bits of data
• Two 1MB bit banding regions for memory and peripherals mapping to 32MB alias regions
• Atomic operation, cannot be interrupted by other bus activities
• 1.25 DMIPS/MHz
• Memory Protection Unit
• Up to 8 protected memory regions
• 24 bits System Tick Timer for Real Time OS
• Excellent 32-bit migration choice for 8/16 bit architecture based designs
• Simplified stack-based programmer's model is compatible with traditional ARM architecture and retains the programming simplicity of legacy 8-bit and 16-bit architectures
• Alligned or unaligned data storage and access
• Contiguous storage of data requiring different byte lengths
• Data access in a single core access cycle
• Integrated power modes
• Sleep Now mode for immediate transfer to low power state
• Sleep on Exit mode for entry into low power state after the servicing of an interrupt
• Ability to extend power savings to other system components
• Optimized for low latency, nested interrupts
3.3 Functional Description
For a full functional description of the ARM Cortex-M3 implementation in the EFM32 Jade Gecko family, the reader is referred to the
ARM Cortex-M3 documentation.
The interrupt request (IRQ) lines are connected to the Cortex-M3. Each of these lines (shown in Table 3.1 Interrupt Request Lines (IRQ)
on page 13) is connected to one or more interrupt flags in one or more modules. The interrupt flags are set by hardware on an inter-
rupt condition. It is also possible to set/clear the interrupt flags through the IFS/IFC registers. Each interrupt flag is then qualified with its
own interrupt enable bit (IEN register), before being OR'ed with the other interrupt flags to generate the IRQ. A high IRQ line will set the
corresponding pending bit (can also be set/cleared with the SETPEND/CLRPEND bits in ISPR0/ICPR0) in the Cortex-M3 NVIC. The
pending bit is then qualified with an enable bit (set/cleared with SETENA/CLRENA bits in ISER0/ICER0) before generating an interrupt
request to the core. Figure 3.1 Interrupt Operation on page 12 illustrates the interrupt system. For more information on how the interrupts are handled inside the Cortex-M3, the reader is referred to the EFM32 Cortex-M3 Reference Manual.
3.3.1.1 Avoiding Extraneous Interrupts
There can be latencies in the system such that clearing an interrupt flag could take longer than leaving an Interrupt Service Routine
(ISR). This can lead to the ISR being re-entered as the interrupt flag has yet to clear immediately after leaving the ISR. To avoid this,
when clearing an interrupt flag at the end of an ISR, the user should execute ARM's Data Synchronization Barrier (DSB) instruction.
Another approach is to clear the interrupt flag immediately after identifying the interrupt source and then service the interrupt as shown
in the pseudo-code below. The ISR typically is sufficiently long to more than cover the few cycles it may take to clear the interrupt status, and also allows the status to be checked for further interrupts before exiting the ISR.
irqXServiceRoutine() {
do {
clearIrqXStatus();
serviceIrqX();
} while(irqXStatusIsActive());
}
3.3.1.2 IFC Read-clear Operation
In addition to the normal interrupt setting and clearing operations via the IFS/IFC registers, there is an additional atomic Read-clear
operation that can be enabled by setting IFCREADCLEAR=1 in the MSC_CTRL register. When enabled, reads of peripheral IFC registers will return the interrupt vector (mirroring the IF register), while at the same time clearing whichever interrupt flags are set. This operation is functionally equivalent to reading the IF register and then writing the result immediately back to the IFC register.
A low latency memory system including low energy
Flash and RAM with data retention which makes the
energy modes attractive.
Why?
RAM retention reduces the need for storing data in
Flash and enables frequent use of the ultra low energy modes EM2 DeepSleep and EM3 Stop.
How?
Low energy and non-volatile Flash memory stores
program and application data in all energy modes
and can easily be reprogrammed in system. Low
leakage RAM with data retention in EM0 Active to
EM3 Stop removes the data restore time penalty,
and the DMA ensures fast autonomous transfers
with predictable response time.
4.1 Introduction
The EFM32 Jade Gecko contains an AMBA AHB Bus system to allow bus masters to access the memory mapped address space. A
multilayer AHB bus matrix connects the 4 master bus interfaces to the AHB slaves (Figure 4.1 EFM32 Jade Gecko Bus System on
page 14). The bus matrix allows several AHB slaves to be accessed simultaneously. An AMBA APB interface is used for the peripher-
als, which are accessed through an AHB-to-APB bridge connected to the AHB bus matrix. The 4 AHB bus masters are:
• Cortex-M3 ICode: Used for instruction fetches from Code memory (valid address range: 0x00000000 - 0x1FFFFFFF)
• Cortex-M3 DCode: Used for debug and data access to Code memory (valid address range: 0x00000000 - 0x1FFFFFFF)
• Cortex-M3 System: Used for data and debug access to system space. It can access entire memory space except Code memory
(valid address range: 0x20000000 - 0xFFFFFFFF)
• DMA: Can access entire memory space except internal core memory region and Code memory (valid address range: 0x20000000 0xDFFFFFFF)
Figure 4.3. System Address Space with Peripheral Listing
The embedded SRAM is located at address 0x20000000 in the memory map of the EFM32 Jade Gecko. When running code located in
SRAM starting at this address, the Cortex-M3 uses the System bus interface to fetch instructions. This results in reduced performance
as the Cortex-M3 accesses stack, other data in SRAM and peripherals using the System bus interface. To be able to run code from
SRAM efficiently, the SRAM is also mapped in the code space at address 0x10000000. When running code from this space, the CortexM3 fetches instructions through the I/D-Code bus interface, leaving the System bus interface for data access. The SRAM mapped into
the code space can however only be accessed by the CPU, i.e. not the DMA.
The SRAM bit-band alias and peripheral bit-band alias regions are located at 0x22000000 and 0x42000000 respectively. Read and
write operations to these regions are converted into masked single-bit reads and atomic single-bit writes to the embedded SRAM and
peripherals of the EFM32 Jade Gecko.
Note: Bit-banding is only available through the CPU. No other AHB masters (e.g., DMA) can perform Bit-banding operations.
Using a standard approach to modify a single register or SRAM bit in the aliased regions, would require software to read the value of
the byte, half-word or word containing the bit, modify the bit, and then write the byte, half-word or word back to the register or SRAM
address. Using bit-banding, this can be done in a single operation, consuming only two bus cycles. As read-writeback, bit-masking and
bit-shift operations are not necessary in software, code size is reduced and execution speed improved.
The bit-band regions allow each bit in the SRAM and Peripheral areas of the memory map to be addressed. To set or clear a bit in the
embedded SRAM, write a 1 or a 0 to the following address:
The EFM32 Jade Gecko supports bit set and bit clear access to all peripherals except those listed in Table 4.1 Peripherals that Do Not
Support Bit Set and Bit Clear on page 18. The bit set and bit clear functionality (also called Bit Access) enables modification of bit
fields (single bit or multiple bit wide) without the need to perform a read-modify-write (though it is functionally equivalent). Also, the operation is contained within a single bus access (for HF peripherals), unlike the Bit-banding operation described in section 4.2.1 Bit-
banding which consumes two bus accesses per operation. All AHB masters can utilize this feature.
The bit clear aliasing region starts at 0x44000000 and the bit set aliasing region starts at 0x46000000. Thus, to apply a bit set or clear
operation, write the bit set or clear mask to the following addresses:
bit_clear_address = address + 0x04000000
bit_set_address = address + 0x06000000
For bit set operations, bit locations that are 1 in the bit mask will be set in the destination register:
register = (register OR mask)
For bit clear operations, bit locations that are 1 in the bit mask will be cleared in the destination register:
register = (register AND (NOT mask))
Note: It is possible to combine bit clear and bit set operations in order to arbitrarily modify multi-bit register fields, without affecting other
fields in the same register. In this case, care should be taken to ensure that the field does not have intermediate values that can lead to
erroneous behavior. For example, if bit clear and bit set operations are used to change an analog tuning register field from 25 to 26, the
field would initially take on a value of zero. If the analog module is active at the time, this could lead to undesired behavior.
The peripherals listed in Table 4.1 Peripherals that Do Not Support Bit Set and Bit Clear on page 18 do not support Bit Access for any
registers. All other peripherals do support Bit Access, however, there may be cases of certain registers that do not support it. Such
registers have a note regarding this lack of support.
Table 4.1. Peripherals that Do Not Support Bit Set and Bit Clear
The Bus Matrix uses a round-robin arbitration algorithm which enables high throughput and low latency, while starvation of simultaneous accesses to the same bus slave are eliminated. Round-robin does not assign a fixed priority to each bus master. The arbiter does
not insert any bus wait-states during peak interaction. However, one wait state is inserted for master accesses occurring after a prolonged inactive time. This wait state allows for increased power efficiency during master idle time.
4.2.4.2 Access Performance
The Bus Matrix is a multi-layer energy optimized AMBA AHB compliant bus with an internal bandwidth of 4x a single AHB interface.
The Bus Matrix accepts new transfers to be initiated by each master in each cycle without inserting any wait-states. However, the
slaves may insert wait-states depending on their internal throughput and the clock frequency.
The Cortex-M3, DMA Controller, and peripherals (not peripherals in the low frequency clock domain) run on clocks which can be prescaled separately. Clocks and prescaling are described in more detail in 10. CMU - Clock Management Unit .
In general, when accessing a peripheral, the latency in number of HFBUSCLK cycles, not including master arbitration, is given by:
where N
slave cycles
N
bus cycles
N
bus cycles
N
bus cycles
N
bus cycles
is the number of cycles required to access the particular slave, including any wait cycles introduced by the slave.
= (N
= (N
= N
= N
slave cycles
slave cycles
slave cycles
slave cycles
+ 1) × f
+ 1) × f
× f
HFBUSCLK/fHFPERCLK
× f
HFBUSCLK/fHFPERCLK
HFBUSCLK/fHFPERCLK
HFBUSCLK/fHFPERCLK
, best-case write accesses
+ 1, best-case read accesses
- 1, worst-case write accesses
, worst-case read accesses
Figure 4.4. Bus Access Latency (General Case)
Note that a latency of 1 cycle corresponds to 0 wait states.
Additionally, for back-to-back accesses to the same peripheral, the throughput in number of cycles per transfer is given by:
N
bus cycles
N
bus cycles
= N
= (N
slave cycles
slave cycles
× f
HFBUSCLK/fHFPERCLK
+ 1) × f
HFBUSCLK/fHFPERCLK
, write accesses
, read accesses
Figure 4.5. Bus Access Throughput (Back-to-Back Transfers)
Lastly, in the highest performing case, where HFPERCLK equals HFBUSCLK and the slave doesn't introduce any additional wait
states, the access latency in number of cycles is given by:
N
bus cycles
= 1, write accesses
N
bus cycles
= 2, read accesses
Figure 4.6. Bus Access Latency (Max Performance)
Note that the cycle counts in the equations above is in terms of the HFBUSCLK. When the core is prescaled from the bus clock, the
core will see a reduced number of latency cycles given by:
System accesses from the core can receive a bus fault in the following condition(s):
• The core attempts to access an address that is not assigned to any peripheral or other system device. These faults can be enabled
or disabled by setting the ADDRFAULTEN bit appropriately in MSC_CTRL.
• The core attempts to access a peripheral or system device that has its clock disabled. These faults can be enabled or disabled by
setting the CLKDISFAULTEN bit appropriately in MSC_CTRL.
In addition to any condition-specific bus fault control bits, the bus fault interrupt itself can be enabled or disabled in the same way as all
other internal core interrupts.
4.3 Access to Low Energy Peripherals (Asynchronous Registers)
The Low Energy Peripherals are capable of running when the high frequency oscillator and core system is powered off, i.e. in energy
mode EM2 DeepSleep and in some cases also EM3 Stop. This enables the peripherals to perform tasks while the system energy consumption is minimal.
The Low Energy Peripherals are listed in Table 4.3 Low Energy Peripherals on page 19.
All Low Energy Peripherals are memory mapped, with automatic data synchronization. Because the Low Energy Peripherals are running on clocks asynchronous to the high frequency system clock, there are some constraints on how register accesses are performed,
as described in the following sections.
4.3.1 Writing
Every Low Energy Peripheral has one or more registers with data that needs to be synchronized into the Low Energy clock domain to
maintain data consistency and predictable operation. There are two different synchronization mechanisms on the EFM32JG1, immediate synchronization, and delayed synchronization. Immediate synchronization is available for the RTCC and LETIMER, and results in
an immediate update of the target registers. Delayed synchronization is used for the remaining Low Energy Peripherals, and for these
peripherals, a write operation requires 3 positive edges of the clock on the Low Energy Peripheral being accessed. Registers requiring
synchronization are marked "Async Reg" in their description header.
Note: On the Gecko series of devices, all LE peripherals are subject to delayed synchronization.
Write request [0:n]
High Frequency Clock Domain
High Frequency Clock
Write request 0
Write request 1
Write request n
Set 0
Set 1
Set n
Register 0
Register 1
.
.
.
Register n
Syncbusy Register 0
Syncbusy Register 1
.
.
.
Syncbusy Register n
Freeze
Clear 0
Clear 1
Clear n
Low Frequency Clock Domain
Low Frequency ClockLow Frequency Clock
Synchronizer 0
Synchronizer 1
.
.
.
Synchronizer n
Synchronization Done
Register 0 Sync
Register 1 Sync
Register n Sync
.
.
.
Figure 4.8. Write operation to Low Energy Peripherals
After writing data to a register which value is to be synchronized into the Low Energy Peripheral using delayed synchronization, a corresponding busy flag in the <module_name>_SYNCBUSY register (e.g. LETIMER_SYNCBUSY) is set. This flag is set as long as synchronization is in progress and is cleared upon completion.
Note: Subsequent writes to the same register before the corresponding busy flag is cleared is not supported. Write before the busy flag
is cleared may result in undefined behavior. In general the SYNCBUSY register only needs to be observed if there is a risk of multiple
write access to a register (which must be prevented). It is not required to wait until the relevant flag in the SYNCBUSY register is
cleared after writing a register. E.g., EM2 DeepSleep can be entered directly after writing a register.
See Figure 4.9 Write operation to Low Energy Peripherals on page 22 for an overview of the writing mechanism operation.
Write request [0:n]
High Frequency Clock Domain
High Frequency Clock
Write request 0
Write request 1
Write request n
Set 0
Set 1
Set n
Register 0
Register 1
.
.
.
Register n
Syncbusy Register 0
Syncbusy Register 1
.
.
.
Syncbusy Register n
Freeze
Clear 0
Clear 1
Clear n
Low Frequency Clock Domain
Low Frequency ClockLow Frequency Clock
Synchronizer 0
Synchronizer 1
.
.
.
Synchronizer n
Synchronization Done
Register 0 Sync
Register 1 Sync
Register n Sync
.
.
.
Figure 4.9. Write operation to Low Energy Peripherals
4.3.1.2 Immediate Synchronization
In contrast to the peripherals with delayed synchronization, peripherals with immediate synchronization don't experience a delay from a
value is written to it takes effect in the peripheral. They are updated immediately on the peripheral write access. If such a write is done
close to an edge on the clock of the peripheral, the write is delayed to after the clock edge. This will introduce wait-states on the peripheral access.
Peripherals with immediate synchronization each have a SYNCBUSY register. Commands written to a peripheral with immediate synchronization are not executed before the first peripheral clock after the write. In this period, the SYNCBUSY flag for the command register is set, indicating that the command has not yet been performed. Secondly, to maintain compatibility with the Gecko series, the rest
of the SYNCBUSY registers are also present, but these are always 0, indicating that register writes are always safe.
Note: If compatibility with the Gecko series is a requirement for a given application, the rules that apply to delayed synchronization with
respect to SYNCBUSY should also be followed for the peripherals that support immediate synchronization.
When reading from a Low Energy Peripheral, the data read is synchronized regardless if it originates in the Low Energy clock domain
or High Frequency clock domain. See Figure 4.10 Read operation from Low Energy Peripherals on page 23 for an overview of the
reading operation.
Note: Writing a register and then immediately reading the new value of the register may give the impression that the write operation is
complete. This may not be the case. Please refer to the SYNCBUSY register for correct status of the write operation to the Low Energy
Peripheral.
High Frequency Clock DomainLow Frequency Clock Domain
High Frequency Clock
Freeze
Low Frequency ClockLow Frequency Clock
Register 0
Register 1
.
.
.
Register n
Read
Synchronizer
Read Data
Synchronizer 0
Synchronizer 1
.
.
.
Synchronizer n
HW Status Register 0
HW Status Register 1
.
.
.
HW Status Register m
Register 0 Sync
Register 1 Sync
.
.
.
Register n Sync
Low Energy
Peripheral
Main
Function
Figure 4.10. Read operation from Low Energy Peripherals
4.3.3 FREEZE Register
In all Low Energy Peripheral with delayed synchronization there is a <module_name>_FREEZE register (e.g. RTCC_FREEZE). The
register contains a bit named REGFREEZE. If precise control of the synchronization process is required, this bit may be utilized. When
REGFREEZE is set, the synchronization process is halted allowing the software to write multiple Low Energy registers before starting
the synchronization process, thus providing precise control of the module update process. The synchronization process is started by
clearing the REGFREEZE bit.
Note: The FREEZE register is also present on peripherals with immediate synchronization, but there it has no effect
4.4 Flash
The Flash retains data in any state and typically stores the application code, special user data and security information. The Flash
memory is typically programmed through the debug interface, but can also be erased and written to from software.
The primary task of the SRAM memory is to store application data. Additionally, it is possible to execute instructions from SRAM, and
the DMA may be set up to transfer data between the SRAM, Flash and peripherals.
• Up to 32 KB of memory
• Bit-band access support
• Set of RAM blocks may be powered down when not in use
• Data retention of the entire memory in EM0 Active to EM3 Stop
The SRAM memory may be split among two or more different AHB slaves (e.g., RAM0, RAM1, ...) in order to allow simultaneous access to different sections of the memory from two different AHB masters. For example, the Cortex-M3 can access RAM0 while the DMA
controller accesses RAM1 in parallel. See Figure 4.1 EFM32 Jade Gecko Bus System on page 14 for AHB slave connectivity details.
The DI page contains production calibration data as well as device identification information. See the peripheral chapters for how each
calibration value is to be used with the associated peripheral.
The offset address is relative to the start address of the DI page.(see 6.3 Functional Description)
OffsetNameTypeDescription
0x000CALROCRC of DI-page and calibration temperature
0x028EUI48LROEUI48 OUI and Unique identifier
0x02CEUI48HROOUI
0x030CUSTOMINFOROCustom information
0x034MEMINFOROFlash page size and misc. chip information
0x040UNIQUELROLow 32 bits of device unique number
0x044UNIQUEHROHigh 32 bits of device unique number
0x048MSIZEROFlash and SRAM Memory size in kB
0x04CPARTROPart description
0x050DEVINFOREVRODevice information page revision
0x054EMUTEMPROEMU Temperature Calibration Information