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
Page 2
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
The Debug Interface is used to program and debug
EFM32 Jade Gecko devices.
Why?
The Debug Interface makes it easy to re-program
and update the system in the field, and allows debugging with minimal I/O pin usage.
How?
ARM Cortex-M3
The Cortex-M3 supports advanced debugging features. EFM32 Jade Gecko devices can use a minimum of two port pins for debugging or programming.
The internal and external state of the system can be
examined with debug extensions supporting instruction or data access break and watch points.
DBG
Debug Data
5.1 Introduction
The EFM32 Jade Gecko devices include hardware debug support through a 2-pin serial-wire debug (SWD) interface or a 4-pin Joint
Test Action Group (JTAG) interface .
For more technical information about the debug interface the reader is referred to:
• ARM Cortex-M3 Technical Reference Manual
• ARM CoreSight Components Technical Reference Manual
• ARM Debug Interface v5 Architecture Specification
• IEEE Standard for Test Access Port and Boundary-Scan Architecture, IEEE 1149.1-2013
5.2 Features
• Debug Access Port Serial Wire JTAG (DAPSWJ)
• Implements the ADIv5 debug interface
• Authentication Access Point (AAP)
• Implements various user commands
• Flash Patch and Breakpoint (FPB) unit
• Implement breakpoints and code patches
• Data Watch point and Trace (DWT) unit
• Implement watch points, trigger resources and system profiling
• Instrumentation Trace Macrocell (ITM)
• Application-driven trace source that supports printf style debugging
The following pins are the debug connections for the device:
• Serial Wire Clock Input and Test Clock Input (SWCLKTCK) : This pin is enabled after reset and has a built-in pull down.
• Serial Wire Data Input/Output and Test Mode Select Input (SWDIOTMS) : This pin is enabled after reset and has a built-in pull-up.
• Test Data Output (TDO): This pin is disabled after reset.
• Test Data Input (TDI): This pin is disabled after reset. Once enabled, the pin has a built-in pull-up.
The debug pins have pull-down and pull-up enabled by default, so leaving them enabled may increase the current consumption if left
connected to supply or ground. The debug pins can be enabled and disabled through GPIO_ROUTE_PEN, see 26.3.4.2.3 Disabling
Debug Connections. Please remember that upon disabling the debug pins, debug contact with the device is lost once the DAPSWJ
power request bits are deasserted. If enabling the JTAG pins, the part must be power cycled to enable a SWD debug session.
5.3.2 Debug and EM2 DeepSleep/EM3 Stop
Leaving the debugger connected when issuing a WFI or WFE to enter EM2 DeepSleep or EM3 Stop will make the system enter a special EM2 DeepSleep. This mode differs from regular EM2 DeepSleep and EM3 Stop in that the high frequency clocks are still enabled,
and certain core functionality is still powered in order to maintain debug-functionality. Because of this, the current consumption in this
mode is closer to EM1 Sleep and it is therefore important to deassert the power requests in the DAPSWJ and disconnect the debugger
before doing current consumption measurements.
5.3.3 Authentication Access Point
The Authentication Acces Point (AAP) is a set of registers that provide a minimal amount of debugging and system level commands.
The AAP registers contain commands to issue a FLASH erase, a system reset, a CRC of user code pages, and stalling the system bus.
The user must program the APSEL bit field to 255 inside of the ARM DAPSWJ Debug Port SELECT register to access the AAP. The
AAP is only accessible from a debugger and not from the core.
5.3.3.1 Command Key
The AAP uses a command key to enable the DEVICEERASE and SYSRESETREQ AAP commands. The command key must be written with the correct key in order for the commands to execute.
5.3.3.2 Device Erase
The device can be erased by writing AAP_CMDKEY followed by writing the DEVICEERASE register bit. Upon writing the command bit,
the ERASEBUSY bit is asserted. The ERASEBUSY bit will be de-asserted once the erase is complete. The SYSRESETREQ bit must
then be set to resume a normal debugger session. The DEVICEERASE register is available at all times through the AAP once the
CMDKEY is enetered.
5.3.3.3 System Reset
The system can be reset by writing AAP_CMDKEY followed by writing the SYSRESTREQ register bit. This must be done afer asserting
DEVICEERASE or CRCREQ. Depending on the reset level setting for system reset, asserting SYSRESETREQ will either reset the entire AAP register space or just the SYSRESETREQ bit. See 8.3.1 Reset levels for more details on reset levels. The SYSRESETREQ
register is available at all times through the AAP once the CMDKEY is enetered.
5.3.3.4 System Bus Stall
The system bus can be stalled at any time using the SYSBUSSTALL register bit. Once the SYSBUSSTALL is set, the system bus will
remain stalled until SYSBUSSTALL is cleared. While the system bus is stalled, only the registers inside the Cortex-M3, AAP and the
debugger can be accessed. The SYSBUSSTALL register is available at all times through the AAP.
5.3.3.5 User Flash Page CRC
The CRCREQ command initiates a CRC calculation on a given Flash Page. The CRC is only available on the Main, User Data, and
Lock Bit pages. It is highly recommended that the system bus is stalled before any CRCREQ commands are issued. The CRC calculation uses the on chip CRC block configured in 32 bit CRC mode. The Flash Page address for the CRCREQ command is written to the
CRCADDR register. After issuing the CRCREQ, the CRCBUSY flag is asserted. Once the CRCBUSY flag is de-asserted, the resulting
page CRC can be found in the CRCRESULT register. Once issuing a CRC command, the CPU is stalled and remains stalled until a
system reset occurs. Multiple CRC requests can occur before resetting the system. However, a CRC request that occurs while the
CRCBUSY flag is asserted will be ignored. The CRC registers are available at all times through the AAP.
The debug access to the Cortex-M3 is locked by clearing the Debug Lock Word (DLW) and resetting the device, see 6.3.2 Lock Bits
(LB) Page Description.
When debug access is locked, the debugger can access the DAPSWJ and AAP registers. However, the connection to the Cortex-M3
core and the whole bus-system is blocked. This mechanism is controlled by the Authentication Access Port (AAP) as illustrated by
Figure 5.1 AAP - Authentication Access Port on page 63.
SerialWire
debug
interface
ALW[3:0] == 0xF
DLW[3:0] == 0xF
SW-DPAHB-AP
Authentication
Access Port
(AAP)
Cortex
DEVICEERASE
ERASEBUSY
Figure 5.1. AAP - Authentication Access Port
If the DLW is cleared, the device is locked. If the device is locked and the the AAP Lock Word (ALW) has not been cleared, it can be
unlocked by writing a valid key to the AAP_CMDKEY register and then setting the DEVICEERASE bit of the AAP_CMD register via the
debug interface. This operation erases the main block of flash, clears all lock bits, and debug access to the Cortex-M3 and bus-system
is enabled. The operation takes tens of mili seconds to complete. Note that the SRAM contents will also be deleted during a device
erase, while the UD-page is not erased.
The debugger may read the status of the device erase from the AAP_STATUS register. When the ERASEBUSY bit is set low after
DEVICEERASE of the AAP_CMD register is set, the debugger may set the SYSRESETREQ bit in the AAP_CMD register. After reset,
the debugger may resume a normal debug session through the AHB-AP.
5.3.5 AAP Lock
Take extreme caution when using this feature. Once the AAP has been locked, the state of the FLASH can not be changed via the
debugger.
5.3.6 Debugger reads of actionable registers
Some peripheral registers cause particular actions when read, e.g FIFOs which pop and IFC registers which clear the IF flags when
read. This can cause problems when debugging and the user wants to read the value without triggering the read action. For this reason, by default, the peripherals will not execute these triggered actions when an attached debugger is performing the read accesses
through the AAP. To override this behavior, the debugger can configure the MASTERTYPE bitfield of the Cortex-M3 AHB Access Port
CSW register in order to emulate a core access when performing system bus transfers.
Note: Registers with actionable reads are noted in their register descriptions. Please refer to Table 1.1 Register Access Types on page
Debug recovery is the ability to stall the system bus before the Cortex-M3 executes code. For example, the first few instructions may
disconnect the debugger pins. When this occurs it is difficult to connect the debugger and halt the Cortex-M3 before the Cortex-M3
starts to execute. By holding down pin reset, issuing the System Bus Stall AAP instruction, then releasing pin reset, the debugger can
stall the system bus before the Cortex-M3 has a chance to execute. Because the system is under reset during this procedure the Debugger can not look for ACK's from the part. Once the system bus is stalled, the FLASH can be erased by issuing the AAP_CMDKEY
and then the writting the DEVICEERASE in the AAP_CMD register.
5.4 Register Map
The offset register address is relative to the registers base address.
OffsetNameTypeDescription
0x000AAP_CMDW1Command Register
0x004AAP_CMDKEYW1Command Key Register
0x008AAP_STATUSRStatus Register
0x00CAAP_CTRLRWControl Register
0x010AAP_CRCCMDW1CRC Command Register
0x014AAP_CRCSTATUSRCRC Status Register
0x018AAP_CRCADDRRWCRC Address Register
0x01CAAP_CRCRESULTRCRC Result Register
0x0FCAAP_IDRRAAP Identification Register
5.5 Register Description
5.5.1 AAP_CMD - Command Register
OffsetBit Position
0x000
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
Reset
Access
Name
BitNameResetAccess Description
12
9
8
7
6
5
4
3
2
1
11
10
0
0
0
W1
W1
SYSRESETREQ
DEVICEERASE
31:2ReservedTo ensure compatibility with future devices, always write bits to 0. More information in 1.2 Conven-
tions
1SYSRESETREQ0W1System Reset Request
A system reset request is generated when set to 1. This register is write enabled from the AAP_CMDKEY register.
0DEVICEERASE0W1Erase the Flash Main Block, SRAM and Lock Bits
When set, all data and program code in the main block is erased, the SRAM is cleared and then the Lock Bit (LB) page is
erased. This also includes the Debug Lock Word (DLW), causing debug access to be enabled after the next reset. The information block User Data page (UD) is left unchanged, but the User data page Lock Word (ULW) is erased. This register is
write enabled from the AAP_CMDKEY register.
The MSC allows the application code, user data and
flash lock bits to be stored in non-volatile Flash
memory. Certain memory system functions, such as
program memory wait-states and bus faults are also
configured from the MSC peripheral register interface, giving the developer the ability to dynamically
customize the memory system performance, security level, energy consumption and error handling capabilities to the requirements at hand.
How?
The MSC integrates a low-energy Flash IP with a
charge pump, enabling minimum energy consumption while eliminating the need for external programming voltage to erase the memory. An easy to use
write and erase interface is supported by an internal,
fixed-frequency oscillator and autonomous flash timing and control reduces software complexity while
not using other timer resources.
Application code may dynamically scale between
high energy optimization and high code execution
performance through advanced read modes.
A highly efficient low energy instruction cache reduces the number of flash reads significantly, thus
saving energy. Performance is also improved when
wait-states are used, since many of the wait-states
are eliminated. Built-in performance counters can be
used to measure the efficiency of the instruction
cache.
6.1 Introduction
The Memory System Controller (MSC) is the program memory unit of the EFM32 Jade Gecko microcontroller. The flash memory is
readable and writable from both the Cortex-M3 and DMA. The flash memory is divided into two blocks; the main block and the information block. Program code is normally written to the main block. Additionally, the information block is available for special user data and
flash lock bits. There is also a read-only page in the information block containing system and device calibration data, and bootloader.
Read and write operations are supported in the energy modes EM0 Active and EM1 Sleep.
The size of the main block is device dependent. The largest size available is 256 KB (128 pages). The information block has 2048
available for user data. The information block also contains chip configuration data located in a reserved area. The main block is mapped to address 0x00000000 and the information block is mapped to address 0x0FE00000. Table 6.1 MSC Flash Memory Mapping on
page 71 outlines how the Flash is mapped in the memory space. All Flash memory is organized into 2048 pages.
00x00000000Software, debugYesUser code and data16 KB - 256 KB
.Software, debugYes
1270x0003F800Software, debugYes
Reserved-0x00040000--Reserved for flash ex-
~24 MB
pansion
Information00x0FE00000Software, debugYesUser Data (UD)2 KB
-0x0FE00800--Reserved-
10x0FE04000Write: Software,
YesLock Bits (LB)2 KB
debug
Erase: Debug only
-0x0FE04800--Reserved-
20x0FE081B0-YesDevice Information (DI)1 KB
-0x0FE08400--Reserved-
20x0FE0C000--1 KB
-0x0FE0C400--Reserved-
30x0FE10000-YesBootloader (BL)10 KB
.--
70x0FE12000--
Reserved-0x0FE12800-Reserved for flash
Rest of code space
expansion
1Block/page erased by a device erase
6.3.1 User Data (UD) Page Description
This is the user data page in the information block. The page can be erased and written by software. The page is erased by the ERASEPAGE command of the MSC_WRITECMD register. Note that the page is not erased by a device erase operation. The device erase
operation is described in 5.3.3 Authentication Access Point.
• Authentication Access Port (AAP) lock word (ALW)
• Bootloader enable (CLW0)
• Pin reset soft (CLW0)
The words in this page are organized as shown in Table 6.2 Lock Bits Page Structure on page 72:
Table 6.2. Lock Bits Page Structure
127DLW
126ULW
125MLW
124ALW
122CLW0
EFM32JG1 Reference Manual
MSC - Memory System Controller
NPLW[N]
……
1PLW[1]
0PLW[0]
There are 32 page lock bits per page lock word (PLW). Bit 0 refers to the first page and bit 31 refers to the last page within a PLW.
Thus, PLW[0] contains lock bits for page 0-31 in the main block, PLW[1] contains lock bits for page 32-63 etc. A page is locked when
the bit is 0. A locked page cannot be erased or written.
Word 127 is the debug lock word (DLW). The four LSBs of this word are the debug lock bits. If these bits are 0xF, then debug access is
enabled. Debug access to the core is disabled from power-on reset until the DLW is evaluated immediately before the Cortex-M3 starts
execution of the user application code. If the bits are not 0xF, then debug access to the core remains blocked.
Word 126 is the user page lock word (ULW). Bit 0 of this word is the User Data Page lock bit. Bit 1 in this word locks the Lock Bits
Page. The lock bits can be reset by a device erase operation initiated from the Authentication Access Port (AAP) registers. The AAP is
described in more detail in 5.3.3 Authentication Access Point. Note that the AAP is only accessible from the debug interface, and cannot be accessed from the Cortex-M3 core.
Word 125 is the mass erase lock word (MLW). Bit 0 locks the entire flash. The mass erase lock bits will not have any effect on device
erases initiated from the Authenitcation Access Port (AAP) registers. The AAP is described in more detail in 5.3.3 Authentication Ac-
cess Point.
Word 124 is the Authentication Access Port (AAP) lock word (ALW) and the four LSBs of this word are the lock bits. If these bits are
0xF, then AAP access is enabled. If the bits are not 0xF, AAP is disabled and it is impossible to access the device through the AAP.
NOTE - locking AAP is irreversible. Once AAP is locked, it will be impossible to perform an external mass erase and AAP lock
cannot be reset. The only way to program the device when AAP is locked is through a boot loader or by SW already loaded into the
FLASH.
Word 122 is configuration word Zero. Bit[2] is the pinresetsoft bit. Bit[1] is the bootloader enable bit. .
6.3.3 Device Information (DI) Page
This read-only page holds oscillator and ADC calibration data from the production test as well as an unique device ID. The page is
further described in .
6.3.4 Bootloader
Bootloader is readable by software but not writable. The system is configured to boot from bootloader automatically after system reset.
User can bypass the bootloader by clear bit 1 in config lock word0 (CLW0) in word 122 of lockbit (LB) page.
Family, FamilyAlt, RevMajor, RevMajorAlt, RevMinor can be accessed through ROM Table. The Revision number is extracted from the
PID2 and PID3 registers, as illustrated in Figure 6.1 Revision Number Extraction on page 73.The Rev[7:4] and Rev[3:0] must be combined to form the complete revision number Revision[7:0].
PID2 (0xE00FFFE8)
31:87:4
Rev[7:4]
3:0
PID3 (0xE00FFFEC)
31:87:4
Rev[3:0]
3:0
Figure 6.1. Revision Number Extraction
The Revision number is to be interpreted according to Table 6.3 Revision Number Interpretation on page 73.
Table 6.3. Revision Number Interpretation
Revision[7:0]Revision
0x00A
6.3.6 Post-reset Behavior
Calibration values are automatically written to registers by the MSC before application code startup. The values are also available to
read from the DI page for later reference by software. Other information such as the device ID and production date is also stored in the
DI page and is readable from software.
If bootloader is not bypassed, the system will boot up from the bootloader at address 0x0FE10000.
6.3.7 Flash Startup
On transitions from EM2/3 to EM0, the flash must be powered up. The time this takes depends on the current operating conditions. To
have a deterministic startup-time, set STDLY0 in MSC_STARTUP to 0x64 and clear STDLY1, ASTWAIT, STWSEN and STWS. This will
result in a 10 us delay before the flash is ready. The system will wake up before this, but the Cortex will stall on the first access to the
flash until it is ready. Execute code from RAM or cache to get a quicker startup
To get the fastest possible startup when wakeup, i.e. a startup that depends on the current operating conditions, set STDLY0 to 0x28
and set ASTWAIT in MSC_STARTUP. When configured this way, the system will poll the flash to determine when it is ready, and then
start execution.
For even quicker startup, run code in beginning with a set of wait-states. Set STDLY0 to 0x32, STDLY1 to 0x32, and set ASTWAIT and
STWSEN. Then configure STWS in MSC_STARTUP to the number of waitstates to run with. With this setup, sampling will begin with
the given number of waitstates after 5 us, and the system will run with this number of waitstates for the remaining 5 us before returning
to normal operation
A recommended setting for MSC_STARTUP register is to set STDLY0 to 0x32 for wait 5us and set ASTWAIT to one for active sampling
Set STWSEN to zero to bypass second delay period.
Flash wakeup on demand is supported when wakeup from EM2/3 to EM0. Set bit PWRUPONDEMAND of register MSC_CTRL to one
to enable the power up on demand. When enabled during powerup, flash will enter sleep mode and waiting for either pending flash
read transaction or software command to MSC_CMD.PWRUP bit. If software command wakeup, and interrupt of MSC_IF.PWRUPF will
be flaged if the MSC_IEN.PWRUPF is set
After reset, the HFCORECLK is normally 19 MHz from the HFRCO and the MODE field of the MSC_READCTRL register is set to WS1
(one wait-state). The reset value must be WS1 as an uncalibrated HFRCO may produce a frequency higher than 32 MHz. Software
must not select a zero wait-state mode unless the clock is guaranteed to be 32 MHz or below, otherwise the resulting behavior is undefined. If a HFCORECLK frequency above 32 MHz is to be set by software, the MODE field of the MSC_READCTRL register must be
set to WS1 or WS1SCBTP before the core clock is switched to the higher frequency clock source.
When changing to a lower frequency, the MODE field of the MSC_READCTRL register must be set to WS0 or WS0SCBTP only after
the frequency transition has completed. If the HFRCO is used, wait until the oscillator is stable on the new frequency. Otherwise, the
behavior is unpredictable.
To run at a frequency higher than 40 MHz, WS2 or WS2SCBTP must be selected to insert two wait-states for every flash access.
6.3.8.2 Zero Wait-state Access
At 32 MHz and below, read operations from flash may be performed without any wait-states. Zero wait-state access greatly improves
code execution performance at frequencies from 32 MHz and below. By default, the Cortex-M3 uses speculative prefetching and IfThen block folding to maximize code execution performance at the cost of additional flash accesses and energy consumption.
6.3.8.3 Operation Above
To run at frequencies higher than 32 MHz, MODE in MSC_READCTRL must be set to WS1 or WS1SCBTP.
MSC offers a special instruction fetch mode which optimizes energy consumption by cancelling Cortex-M3 conditional branch target
prefetches. Normally, the Cortex-M3 core prefetches both the next sequential instruction and the instruction at the branch target address when a conditional branch instruction reaches the pipeline decode stage. This prefetch scheme improves performance while one
extra instruction is fetched from memory at each conditional branch, regardless of whether the branch is taken or not. To optimize for
low energy, the MSC can be configured to cancel these speculative branch target prefetches. With this configuration, energy consumption is more optimal, as the branch target instruction fetch is delayed until the branch condition is evaluated.
The performance penalty with this mode enabled is source code dependent, but is normally less than 1% for core frequencies from 32
MHz and below. To enable the mode at frequencies from 32 MHz and below write WS0SCBTP to the MODE field of the
MSC_READCTRL register. For frequencies above 32 MHz, use the WS1SCBTP mode, and for frequencies above 40 MHz, use the
WS2SCBTP mode. An increased performance penalty per clock cycle must be expected compared to WS0SCBTP mode. The performance penalty in WS1SCBTP/WS2SCBTP mode depends greatly on the density and organization of conditional branch instructions in
the code.
6.3.10 Cortex-M3 If-Then Block Folding
The Cortex-M3 offers a mechanism known as if-then block folding. This is a form of speculative prefetching where small if-then blocks
are collapsed in the prefetch buffer if the condition evaluates to false. The instructions in the block then appear to execute in zero cycles. With this scheme, performance is optimized at the cost of higher energy consumption as the processor fetches more instructions
from memory than it actually executes. To disable the mode, write a 1 to the DISFOLD bit in the NVIC Auxiliary Control Register; see
the Cortex-M3 Technical Reference Manual for details. Normally, it is expected that this feature is most efficient at core frequencies
above 32 MHz. Folding is enabled by default.
The MSC includes an instruction cache. The instruction cache for the internal flash memory is enabled by default, but can be disabled
by setting IFCDIS in MSC_READCTRL. When enabled, the instruction cache typically reduces the number of flash reads significantly,
thus saving energy. In most cases a cache hit-rate of more than 70 % is achievable. When a 32-bit instruction fetch hits in the cache the
data is returned to the processor in one clock cycle. Thus, performance is also improved when wait-states are used (i.e. running at
frequencies above 32 MHz).
The instruction cache is connected directly to the ICODE bus on the ARM core and functions as a memory access filter between the
processor and the memory system, as illustrated in Figure 6.2 Instruction Cache on page 75. The cache consists of an access filter,
lookup logic, SRAM, and two performance counters. The access filter checks that the address for the access is to on-chip flash memory
(instructions in RAM are not cached). If the address matches, the cache lookup logic and SRAM is enabled. Otherwise, the cache is
bypassed and the access is forwarded to the memory system. The cache is then updated when the memory access completes. The
access filter also disables cache updates for interrupt context accesses if caching in interrupt context is disabled. The performance
counters, when enabled, keep track of the number of cache hits and misses. The cachelines are filled up continuously one word at a
time as the individual words are requested by the processor. Thus, not all words of a cacheline might be valid at a given time.
Instruction Cache
Cache
CODE
Memory Space
IDCODE
AHB-Lite Bus
IDCODE
MUX
ICODE
AHB-Lite Bus
Look-up Logic
SRAM
Performance Counters
Access
Filter
ICODE
AHB-Lite Bus
ARM Core
DCODE
AHB-Lite Bus
Figure 6.2. Instruction Cache
By default, the instruction cache is automatically invalidated when the contents of the flash is changed (i.e. written or erased). In many
cases, however, the application only makes changes to data in the flash, not code. In this case, the automatic invalidate feature can be
disabled by setting AIDIS in MSC_READCTRL. The cache can (independent of the AIDIS setting) be manually invalidated by writing 1
to INVCACHE in MSC_CMD.
In general it is highly recommended to keep the cache enabled all the time. However, for some sections of code with very low cache hitrate more energy-efficient execution can be achieved by disabling the cache temporarily. To measure the hit-rate of a code-section, the
built-in performance counters can be used. Before the section, start the performance counters by writing 1 to STARTPC in MSC_CMD.
This starts the performance counters, counting from 0. At the end of the section, stop the performance counters by writing 1 to
STOPPC in MSC_CMD. The number of cache hits and cache misses for that section can then be read from MSC_CACHEHITS and
MSC_CACHEMISSES respectively. The total number of 32-bit instruction fetches will be MSC_CACHEHITS + MSC_CACHEMISSES.
Thus, the cache hit-ratio can be calculated as MSC_CACHEHITS / (MSC_CACHEHITS + MSC_CACHEMISSES). When MSC_CACHEHITS overflows the CHOF interrupt flag is set. When MSC_CACHEMISSES overflows the CMOF interrupt flag is set. These flags
must be cleared explicitly by software. The range of the performance counters can thus be extended by increasing a counter in the
MSC interrupt routine. The performance counters only count when a cache lookup is performed. If the lookup fails, MSC_CACHEMISSES is increased. If the lookup is successful, MSC_CACHEHITS is increased. For example, a cache lookup is not performed if the cache
is disabled or the code is executed from RAM. When caching of vector fetches and instructions in interrupt routines is disabled (ICCDIS
in MSC_READCTRL is set), the performance counters do not count when these types of fetches occur (i.e. while in interrupt context).
By default, interrupt vector fetches and instructions in interrupt routines are also cached. Some applications may get better cache utilization by not caching instructions in interrupt context. This is done by setting ICCDIS in MSC_READCTRL. You should only set this bit
based on the results from a cache hit ratio measurement. In general, it is recommended to keep the ICCDIS bit cleared. Note that lookups in the cache are still performed, regardless of the ICCDIS setting - but instructions are not cached when cache misses occur inside
the interrupt routine. So, for example, if a cached function is called from the interrupt routine, the instructions for that function will be
taken from the cache.
The cache content is not retained in EM2, EM3 and EM4. The cache is therefore invalidated regardless of the setting of AIDIS in
MSC_READCTRL when entering these energy modes. Applications that switch frequently between EM0 and EM2/3 and executes the
very same non-looping code almost every time will most likely benefit from putting this code in RAM. The interrupt vectors can also be
put in RAM to reduce current consumption even further.
Both page erase and write operations require that the address is written into the MSC_ADDRB register. For erase operations, the address may be any within the page to be erased. Load the address by writing 1 to the LADDRIM bit in the MSC_WRITECMD register.
The LADDRIM bit only has to be written once when loading the first address. After each word is written the internal address register
ADDR will be incremented automatically by 4. The INVADDR bit of the MSC_STATUS register is set if the loaded address is outside the
flash and the LOCKED bit of the MSC_STATUS register is set if the page addressed is locked. Any attempts to command erase of or
write to the page are ignored if INVADDR or the LOCKED bits of the MSC_STATUS register are set. To abort an ongoing erase, set the
ERASEABORT bit in the MSC_WRITECMD register.
When a word is written to the MSC_WDATA register, the WDATAREADY bit of the MSC_STATUS register is cleared. When this status
bit is set, software or DMA may write the next word.
A single word write is commanded by setting the WRITEONCE bit of the MSC_WRITECMD register. The operation is complete when
the BUSY bit of the MSC_STATUS register is cleared and control of the flash is handed back to the AHB interface, allowing application
code to resume execution.
For a DMA write the software must write the first word to the MSC_WDATA register and then set the WRITETRIG bit of the
MSC_WRITECMD register. DMA triggers when the WDATAREADY bit of the MSC_STATUS register is set.
It is possible to write words twice between each erase by keeping at 1 the bits that are not to be changed. Let us take as an example
writing two 16 bit values, 0xAAAA and 0x5555. To safely write them in the same flash word this method can be used:
• Write 0xFFFFAAAA (word in flash becomes 0xFFFFAAAA)
• Write 0x5555FFFF (word in flash becomes 0x5555AAAA)
Note that there is a maximum of two writes to the same word between each erase due to a physical limitation of the flash.
Note:
During a write or erase, flash read accesses will be stalled, effectively halting code execution from flash. Code execution continues
upon write/erase completion. Code residing in RAM may be executed during a write/erase operation.
6.3.12.1 Mass erase
A mass erase can be initiated from software using ERASEMAIN0 MSC_WRITECMD. This command will start a mass erase of the entire flash. Prior to initiating a mass erase, MSC_MASSLOCK must be unlocked by writing 0x631A to it. After a mass erase has been
started, this register can be locked again to prevent runaway code from accidentally triggering a mass erase.
The regular flash page lock bits will not prevent a mass erase. To prevent software from initiating mass erases, use the mass erase lock
bits in the mass erase lock word (MLW).
31:4ReservedTo ensure compatibility with future devices, always write bits to 0. More information in 1.2 Conven-
tions
3IFCREADCLEAR0RWIFC Read Clears IF
This bit controls what happens when an IFC register in a module is read.
ValueDescription
0IFC register reads 0. No side-effect when reading.
1IFC register reads the same value as IF, and the corresponding inter-
rupt flags are cleared.
0
1
RW
ADDRFAULTEN
2PWRUPONDEMAND 0RWPower Up On Demand During Wake Up
When set, during wake up, pending AHB transfer will cause MSC to issue power up request to CMU. If not set, will always
issue power up request if PWRUPONCMD is not set either.
1CLKDISFAULTEN0RWClock-disabled Bus Fault Response Enable
When this bit is set, busfaults are generated on accesses to peripherals/system devices with clocks disabled
0ADDRFAULTEN1RWInvalid Address Bus Fault Response Enable
When this bit is set, busfaults are generated on accesses to unmapped parts of system and code address space
Enable suppressed Conditional Branch Target Prefetch (SCBTP) function. SCBTP saves energy by delaying Cortex-M4
conditional branch target prefetches until the conditional branch instruction is in the execute stage. When the instruction
reaches this stage, the evaluation of the branch condition is completed and the core does not perform a speculative prefetch of both the branch target address and the next sequential address. With the SCBTP function enabled, one instruction
fetch is saved for each branch not taken, with a negligible performance penalty.
27:26ReservedTo ensure compatibility with future devices, always write bits to 0. More information in 1.2 Conven-
tions
25:24MODE0x1RWHRead Mode
After reset, the core clock is 19 MHz from the HFRCO and the MODE field of MSC_READCTRL register is set to WS1. The
reset value is WS1 because the HFRCO may produce a frequency above 19 MHz before it is calibrated. A large wait states
is associated with high frequency. When changing to a higher frequency, this register must be set to a large wait states first
before the core clock is switched to the higher frequency. When changing to a lower frequency, this register should be set
to lower wait states after the frequency transition has been completed. If the HFRCO is used as clock source, wait until the
oscillator is stable on the new frequency to avoid unpredictable behavior.See Flash Wait-States table for the corresponding
threshold for different wait-states.
ValueModeDescription
0WS0Zero wait-states inserted in fetch or read transfers
1WS1One wait-state inserted for each fetch or read transfer. See Flash Wait-
States table for details
23:10ReservedTo ensure compatibility with future devices, always write bits to 0. More information in 1.2 Conven-
tions
9USEHPROT0RWAHB_HPROT Mode
Use ahb_hrpot to determine if the instruction is cacheable or not
8PREFETCH1RWPrefetch Mode
Set to configure level of prefetching.
7:6ReservedTo ensure compatibility with future devices, always write bits to 0. More information in 1.2 Conven-
tions
5ICCDIS0RWInterrupt Context Cache Disable
Set this bit to automatically disable caching of vector fetches and instruction fetches in interrupt context. Cache lookup will
still be performed in interrupt context. When set, the performance counters will not count when these types of fetches occur.
4AIDIS0RWAutomatic Invalidate Disable
When this bit is set the cache is not automatically invalidated when a write or page erase is performed.
3IFCDIS0RWInternal Flash Cache Disable
Disable instruction cache for internal flash memory.
2:0ReservedTo ensure compatibility with future devices, always write bits to 0. More information in 1.2 Conven-
31:2ReservedTo ensure compatibility with future devices, always write bits to 0. More information in 1.2 Conven-
tions
1IRQERASEABORT0RWAbort Page Erase on Interrupt
When this bit is set to 1, any Cortex-M4 interrupt aborts any current page erase operation. Executing that interrupt vector
from Flash will halt the CPU.
0WREN0RWEnable Write/Erase Controller
When this bit is set, the MSC write and erase functionality is enabled
31:13ReservedTo ensure compatibility with future devices, always write bits to 0. More information in 1.2 Conven-
tions
12CLEARWDATA0W1Clear WDATA state
Will set WDATAREADY and DMA request. Should only be used when no write is active.
11:9ReservedTo ensure compatibility with future devices, always write bits to 0. More information in 1.2 Conven-
tions
8ERASEMAIN00W1Mass erase region 0
Initiate mass erase of region 0. Before use MSC_MASSLOCK must be unlocked. To completely prevent access from software, clear bit 0 in the mass erase lock-word (MLW)
0
0
W1
LADDRIM
7:6ReservedTo ensure compatibility with future devices, always write bits to 0. More information in 1.2 Conven-
tions
5ERASEABORT0W1Abort erase sequence
Writing to this bit will abort an ongoing erase sequence.
4WRITETRIG0W1Word Write Sequence Trigger
Start write of the first word written to MSC_WDATA, then add 4 to ADDR and write the next word if available within a 30us
timeout. When ADDR is incremented past the page boundary, ADDR is set to the base of the page. If WDOUBLE is set,
two words are required every time, and ADDR is incremented by 8.
3WRITEONCE0W1Word Write-Once Trigger
Write the word in MSC_WDATA to ADDR. Flash access is returned to the AHB interface as soon as the write operation
completes. The WREN bit in the MSC_WRITECTRL register must be set in order to use this command. Only a single word
is written, but the internal address is also incremented to allow a direct write of a new word without loading a new address
2WRITEEND0W1End Write Mode
Write 1 to end write mode when using the WRITETRIG command.
1ERASEPAGE0W1Erase Page
Erase any user defined page selected by the MSC_ADDRB register. The WREN bit in the MSC_WRITECTRL register must
be set in order to use this command.
0LADDRIM0W1Load MSC_ADDRB into ADDR
Load the internal write address register ADDR from the MSC_ADDRB register. The internal address register ADDR is incremented automatically by 4 after each word is written. When ADDR is incremented past the page boundary, ADDR is set to
the base of the page.
31:0ADDRB0x00000000RWPage Erase or Write Address Buffer
This register holds the page address for the erase or write operation. This register is loaded into the internal MSC_ADDR
register when the LADDRIM field in MSC_CMD is set.
6.5.6 MSC_WDATA - Write Data Register
OffsetBit Position
0x018
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
9
8
7
6
5
4
3
2
1
0
Reset
Access
Name
BitNameResetAccess Description
31:0WDATA0x00000000RWWrite Data
The data to be written to the address in MSC_ADDR. This register must be written when the WDATAREADY bit of
MSC_STATUS is set.
31:7ReservedTo ensure compatibility with future devices, always write bits to 0. More information in 1.2 Conven-
tions
6PCRUNNING0RPerformance Counters Running
This bit is set while the performance counters are running. When one performance counter reaches the maximum value,
this bit is cleared.
5ERASEABORTED0RThe Current Flash Erase Operation Aborted
When set, the current erase operation was aborted by interrupt.
4WORDTIMEOUT0RFlash Write Word Timeout
0
0
R
BUSY
When this bit is set, MSC_WDATA was not written within the timeout. The flash write operation timed out and access to the
flash is returned to the AHB interface. This bit is cleared when the ERASEPAGE, WRITETRIG or WRITEONCE commands
in MSC_WRITECMD are triggered.
3WDATAREADY1RWDATA Write Ready
When this bit is set, the content of MSC_WDATA is read by MSC Flash Write Controller and the register may be updated
with the next 32-bit word to be written to flash. This bit is cleared when writing to MSC_WDATA.
2INVADDR0RInvalid Write Address or Erase Page
Set when software attempts to load an invalid (unmapped) address into ADDR
1LOCKED0RAccess Locked
When set, the last erase or write is aborted due to erase/write access constraints
0BUSY0RErase/Write Busy
When set, an erase or write operation is in progress and new commands are ignored
31:6ReservedTo ensure compatibility with future devices, always write bits to 0. More information in 1.2 Conven-
tions
5ICACHERR0(R)W1Clear ICACHERR Interrupt Flag
Write 1 to clear the ICACHERR interrupt flag. Reading returns the value of the IF and clears the corresponding interrupt
flags (This feature must be enabled globally in MSC.).
4PWRUPF0(R)W1Clear PWRUPF Interrupt Flag
Write 1 to clear the PWRUPF interrupt flag. Reading returns the value of the IF and clears the corresponding interrupt flags
(This feature must be enabled globally in MSC.).
3CMOF0(R)W1Clear CMOF Interrupt Flag
0
0
(R)W1
ERASE
Write 1 to clear the CMOF interrupt flag. Reading returns the value of the IF and clears the corresponding interrupt flags
(This feature must be enabled globally in MSC.).
2CHOF0(R)W1Clear CHOF Interrupt Flag
Write 1 to clear the CHOF interrupt flag. Reading returns the value of the IF and clears the corresponding interrupt flags
(This feature must be enabled globally in MSC.).
1WRITE0(R)W1Clear WRITE Interrupt Flag
Write 1 to clear the WRITE interrupt flag. Reading returns the value of the IF and clears the corresponding interrupt flags
(This feature must be enabled globally in MSC.).
0ERASE0(R)W1Clear ERASE Interrupt Flag
Write 1 to clear the ERASE interrupt flag. Reading returns the value of the IF and clears the corresponding interrupt flags
(This feature must be enabled globally in MSC.).
31:16ReservedTo ensure compatibility with future devices, always write bits to 0. More information in 1.2 Conven-
tions
15:0LOCKKEY0x0000RWHConfiguration Lock
Write any other value than the unlock code to lock access to MSC_CTRL, MSC_READCTRL, MSC_WRITECMD,
MSC_STARTUP and MSC_AAPUNLOCKCMD. Write the unlock code to enable access. When reading the register, bit 0 is
set when the lock is enabled.
31:20ReservedTo ensure compatibility with future devices, always write bits to 0. More information in 1.2 Conven-
tions
19:0CACHEMISSES0x00000RCache misses since last performance counter start command.
Use to measure cache performance for a particular code section.
6.5.16 MSC_MASSLOCK - Mass Erase Lock Register
OffsetBit Position
1
0
0x054
31
30
29
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
Reset
0x0001
Access
RWH
Name
LOCKKEY
BitNameResetAccess Description
31:16ReservedTo ensure compatibility with future devices, always write bits to 0. More information in 1.2 Conven-
tions
15:0LOCKKEY0x0001RWHMass Erase Lock
Write any other value than the unlock code to lock access the the ERASEMAINn commands. Write the unlock code 631A to
enable access. When reading the register, bit 0 is set when the lock is enabled. Locked by default.
The LDMA controller can move data without CPU intervention, effectively reducing the energy consumption for a data transfer.
Why?
The LDMA can perform data transfers more energy
efficiently than the CPU and allows autonomous operation in low energy modes. For example the
LEUART can provide full UART communication in
EM2 DeepSleep, consuming only a few µA by using
the LDMA to move data between the LEUART and
RAM.
How?
The LDMA controller has multiple highly configurable, prioritized DMA channels. A linked list of flexible
descriptors makes it possible to tailor the controller
to the specific needs of an application.
7.1 Introduction
The Linked Direct Memory Access (LDMA) controller performs memory transfer operations independently of the CPU. This has the
benefit of reducing the energy consumption and the workload of the CPU, and enables the system to stay in low energy modes while
still routing data to memory and peripherals. For example, moving data from the LEUART to memory or memory to LEUART. Each of
the DMA channels on the EFM32 can be connected to any of the EFM32 peripherals.
An overview of the LDMA and the modules it interacts with is shown in Figure 7.1 LDMA Block Diagram on page 96.
Cortex
AHB
RAM
Interrupts
Error
Channel
done
LDMA Core
Channel 0
Peripheral
Channel 1
Peripheral
Peripheral
Channel
select
ACK/
REQ
Channel N
Descriptor A
Descriptor B
Descriptor C
Peripheral
LDMA
Figure 7.1. LDMA Block Diagram
The Linked DMA Controller consists of three main parts
• A DMA core that executes transers and communicates status to the core
• A channel select block that routes peripheral DMA requests and acknowledge signals to the DMA
• A set of internal channel configuration registers for tracking the progres of each DMA channel
The DMA has acces to all system memory through the AHB bus and the AHB->APB bridge. It can load channel descriptors from memory with no CPU intervention.
The Linked DMA Controller is highly flexible. It is capable of transferring data between peripherals and memory without involvement
from the processor core. This can be used to increase system performance by off-loading the processor from copying large amounts of
data or avoiding frequent interrupts to service peripherals needing more data or having available data. It can also be used to reduce the
system energy consumption by making the LDMA work autonomously with EM2 peripherals for data transfer in EM2 DeepSleep without
having to wake up the processor core from sleep.
The Linked DMA Controller has 8 independent channels. Each of these channels can be connected to any of the available peripheral
DMA transfer request input sources by writing to the channel configuration registers, see 7.3.2 Channel Configuration. In addition, each
channel can also be triggered directly by software, which is useful for memory-to-memory transfers.
The channel descriptors determine what the Linked DMA Controller will do when it receives DMA transfer request. The initial descriptor
is written directly to the LDMA's channel registers. If desired, the initial descriptor can link to additional linked descriptors stored in memory (RAM or Flash). Alternatively, software may also load the initial descriptor by writing the descriptor address to the LDMA_CHx_LINK
register and then setting the corresponding bit the LDMA_LINKLOAD register.
Before enabling a channel, the software must take care to properly configure the channel registers including the link address and any
linked descriptors. When a channel is triggered, the Linked DMA Controller will perform the memory transfers as specified by the descriptors. A descriptor contains the memory address to read from, the memory address to write to, link address of the next descriptor,
the number of bytes to be transferred, etc. The channel descriptor is described in detail in 7.3.7 Channel descriptor data structure.
The Linked DMA Controller supports both fixed priority and round robin arbitration. The number of fixed and round robin channels is
programmable. For round robin channels, the number of arbitration slots requested for each channel is programmable. Using this
scheme, it is possible to ensure that timing-critical transfers are serviced on time.
DMA transfers take place by reading a block of data at a time from the source, storing it in the LDMA’s local FIFO, then writing the block
out to the destination from the FIFO. Interrupts may optionally be signaled to the CPU’s interrupt controller at the end of any DMA transfer or at the completion of a descriptor if the DONEIFSEN bit is set. An AHB error will always generate an interrupt.
7.3.1 Channel Descriptor
Each DMA channel has descriptor registers. A transfer can be initialized by software writing to the registers or by the DMA itself copying
a descriptor from RAM to memory. When using a linked list of descriptors the first descriptor should be initialized by the CPU. The DMA
itself will then copy linked descriptors to its descriptor registers as required. In addition to manually initializing the first transfer, software
may also cause the LDMA to load the initial descriptor by writing the descriptor address to the LDMA_CHx_LINK register and then setting the corresponding bit the LDMA_LINKLOAD register.
The contents of the descriptor registers are dynamically updated during the DMA transfer. The contents of descriptors in memory are
not edited by the controller.
Some descriptor field values are only used for linked descriptors. For example, the SRCMODE and DSTMODE bits of the
LDMA_CHx_CTRL registers determine if a linked descriptor is using relative or absolute addressing. Software writes to the address
registers will always use absolute addressing and never set these bits. Therefore, these bits are read only.
7.3.1.1 DMA Transfer Size
A DMA transfer is the smallest unit of data that can be transfered by the LDMA. The LDMA supports byte, half-word and word sized
transfers. The SIZE field in the LDMA_CHx_CTRL register specifies the data width of one DMA transfer.
7.3.1.2 Source/Destination Increments
The SRCINC and DSTINC in the LDMA_CHx_CTRL register determines the increment between DMA transfers. The increment is in
units of DMA transfers and using an increment size of 1 will transfer contiguous bytes, half-words, or words depending on the value of
the SIZE field. Multiple unit increments are useful for transferring or packing/unpacking alligned data. For example using an increment
of 4 with a size of BYTE will transfer word aligned bytes. An increment of 2 units witha size of HALFWORD is suitable for the transfer of
word aligned half-word data. The LDMA can pack also pack or unpack data by using a different increment size for source and destination. For example - to convert from word aligned byte data (unpacked) to contigous byte data (packed), set the SIZE to BYTE, SRCINC
to 4, and DSTINC to 1.
SIZE may also be set to NONE which will cause the LDMA to read or write the same location for every DMA transfer. This is usfull for
accessing peripheral FIFO or data registers.
7.3.1.3 Block Size
The block size defines the amount of data transferred in one arbitration. It consists of one or more DMA transfers. See 7.3.6.1 Arbitra-
The descriptor transfer count defines how many DMA transfers to perform. The number of bytes transferred by the descripter will depend on both the transfer count XFERCNT and the SIZE field settings. TOTAL_BYTES = XFERCNT * SIZE
7.3.1.5 Descriptor List
A descriptor list consists of one or more descriptors which are executed in serially. This list may be a simple sequence of descriptors, a
loop of descriptors, or a combination of the two.
Each descriptor in the list can be one of several types.
• Single Transfer descriptor: Transfers TOTAL_BYTES of data and then stops.
• Linked Transfer descriptor: Transfers TOTAL_BYTES of data and then loads the next linked descriptor.
• Loop Transfer descriptor: Transfers TOTAL_BYTES of data and performs loop control (see 7.3.2.2 Loop Counter).
• Sync descriptor: Handle synchronization of the list with other enteties (see 7.3.7.2 SYNC descriptor structure).
• WRI descriptor: Writes a value to a location in memory (see 7.3.7.3 WRI descriptor structure).
7.3.1.6 Addresses
Before initiating a transfer, software should write the source address, destination address, and if applicable the link address to the descriptor registers. Alternatively, software may load a descriptor from memory by writing the descriptor address to the LDMA_CHx_LINK
register and setting the corresponding bit in the LDMA_LINKLOAD register.
During a DMA transfer, the DMA source and destination address registers are pointers to the next transfer address. The LDMA will
update the SRC and DST addresses after each transfer. If software halts a DMA transfer by clearing the enable bit, the SRC and DST
addresses will indicate the next transfer address.
When a desriptor is finished the DMA will either halt or load the next (linked) descriptor depending on the value of the LINK field in the
LDMA_Chx_LINK register. After loading a linked descriptor, the descriptor registers will reflect the content of the loaded descriptor. Note
that the linked descriptor must be word aligned in memory. The two least significant bits of the LDMA_CHx_LINK register are used by
the LINK and LINKMODE bits. The two least significant bits of the link address are always zero.
7.3.1.7 Addressing Modes
The DMA descriptors support absolute addressing or relative addressing. When using relative addressing, the offset is relative to the
current contents of the respective address registers. Regardless of the descriptor addressing modes, the address registers always indicate the absolute address. For example, when loading a descriptor using relative SRC addressing, the LDMA will add the descriptor
source address (offset) to the contents of the SRCADDR register (base address). After loading, the SRCADDR register will indicate the
absolute address of the loaded descriptor.
The initial descriptor must use absolute addressing. The LDMA will ignore the DSTMODE, SRCMODE, and LINKMODE bits for the
initial descriptor and interpret the addresses as an absolute addresses.
Relative addressing is most useful for the link address. The initial descriptor will indicate the absolute address of the linked descriptors
in memory. The linked descriptors might be an array of structures. In this case the offset between descriptors is constant and is always
16 bytes. The LINK address is not incremented or decremented after each transfer. Thus, a relative offset of 0x10 may be used for all
linked descriptors.
The source and destination addresses also support relative addressing. When using relative addressing with the source or destination
address registers, the LDMA adds the relative offset to the current contents of the respective address register. Since the source and
destination addresses are normally incremented after each transfer, the final address will point to one unit past the last transfer. Thus,
an offset of zero will give the next sequential data address.
See the example 7.4.6 2D Copy for an common use of releative addressing.
Enabling byte swap reverses the endianess of the incoming source data read into the LDMA’s FIFO. Byte swap is only valid for transfer
sizes of word and half-word. Note that linked structure reads are not byte swapped.
B3b7 B3b0 B2b7 B2b0 B1b7 B1b0 B0b7 B0b0
B3b7 B3b0 B2b7 B2b0 B1b7 B1b0 B0b7 B0b0
B3B2B1B0
BYTESWAP=1
SIZE=WORD
B3b7 B3b0B2b7 B2b0B1b7 B1b0B0b7 B0b0
B1B0
BYTESWAP=1
SIZE=HALF
B3b7 B3b0B2b7 B2b0B1b7 B1b0B0b7 B0b0
B3B2B1B0
B1B0
Figure 7.2. Word and Half-Word Endian Byte Swap Examples