Information in this document is provided solely to enable system and software
implementers to use Freescale products. There are no express or implied copyright
licenses granted hereunder to design or fabric ate any int egrate d circuit s based on the
information in this document.
Freescale reserves the right to make changes without further notice to any products
herein. Freescale makes no warranty, representation, or guarantee regarding the
suitability of its products for any particular purpose, nor does Freescale assume any
liability arising out of the application or use of any product or circuit, and specifically
disclaims any and all liability, including without limitation consequential or incidental
damages. “Typical” parameters that may be provided in Freescale data sheets and/or
specifications can and do vary in different applications, and actual perfor mance may
vary over time. All operating parameters, including “typicals,” must be validated for
each customer application by customer’s technical experts. Freescale do es not convey
any license under its patent rights nor the rights of others. Freescale sells products
pursuant to standard terms and conditions of sale, which can be found at the following
address: freescale.com/salestermsandconditions.
This reference manual describes the features, architecture and programming model of the MMA955xL
platform, an intelligent, three-axis accelerometer.
1.1.2Audience
This document is primarily for system architects and software application developers who are using or
considering use of the MMA955xL in a system.
1.2Terms and acronyms
AFEAnalog Front End
APP_IDApplication identifier
APIApplication Programming Interface
BDMBackground Debug Module
CCCommand Complete
CICommand Interpreter
CMDCommand
COCOConversion Complete or Command Complete
CSRColdFire Configuration Status Register
DFCData Format Code
DTAPDouble tap (n.)
FIFOFirst In First Out, a data structure
FOPTFlash Options register
GPIOGeneral-Purpose Input/Output, a microcontroller pin that can be programmed by
software
hashA deterministic, cryptographic function that converts an arbitrary block of data
into a fixed-size bit string—the (cryptographic) hash value—such that an
accidental or intentional change to the data will change that hash value
JT AGJoint T e st Action Group (JT AG), the common name for the IEEE 1 149.1 standard
Standard Test Access Port and Boundary-Scan Architecture, for test-access ports
LGLow g
LLLandscape Left
LRLandscape Right
MBOXMailbox
MCUMicrocontroller
MTIMOVModule Timer Overflow Module
PCProgram Counter
PDPortrait Down
PDBProgram Delay Block
PLPortrait/Landscape
PORPower-on Reset
PUPortrait Up
SFDStart Frame Digital
Shared secretEncrypted data known only to the parties involved in a secure communication.
Can include a password, a pass phrase, a big number, or an array of randomly
chosen bytes.
SSPSupervisor Stack Pointer
TPMTimer Program Module
VBRVector Base Register, a register in the ColdFire memory map that controls the
This document uses the following notational conventions:
cleared/setWhen a bit takes the value 0, it is said to be cleared; when it takes a value of 1, it
is said to be set.
MNEMONICSIn text, instruction mnemonics are shown in uppercase.
mnemonicsIn code and tables, instruction mnemonics are shown in lowercase.
italicsItalics indicate variable command parameters.
Book titles also are italicized.
0x0Prefix to denote a hexadecimal number
0b0Prefix to denote a binary number
REG[FIELD]Abbreviations for registers are shown in uppercase. Specific bits, fields or ranges
appear in brackets. For example, RAMBAR[BA] identifies the base address field
in the RAM base-address register.
nibble A 4-bit data unit
byte An 8-bit data unit
word A 16-bit data unit
longword A 32-bit data unit
xIn some contexts, such as signal encodings, x indicates a “do not care.”
nUsed to express an undefined numerical value.
~NOT logical operator
&AND logical operator
|OR logical operator
||Field concatenation operator
OVERBARIndicates that a signal is active-low.
This document uses the following conventions for the register reset values:
—The bit is undefined at reset.
uThe bit is unaffected by reset.
[signal_name]Reset value is determined by the polarity of the indicated signal.
The following register fields are used:
Read0Indicates a reserved bit field in a memory-mapped register. These bits are always read as 0.
Write
Read1Indicates a reserved bit field in a memory-mapped register. These bits are always read as 1.
Write
Read FIELDNAMEIndicates a read/write bit.
Write
Read FIELDNAMEIndicates a read-only bit field in a memory-mapped register.
Write
ReadIndicates a write-only bit field in a memory-mapped register.
Write FIELDNAME
Read FIELDNAMEWrite 1 to clear: indicates that writing a 1 to this bit field clears it.
Writew1c
Read0Indicates a self-clearing bit.
Write FIELDNAME
6. Wikipedia entry for “Semaphore”: http://en.wikipedia.org/wiki/Semaphore_(programming)
7. ITU-T V.41 Recommendation: Code-Independent Error Control System, available at
http://www.itu.int/publications/index.html.
8. ITU-T X.25 Recommendation: Interface between Data Terminal Equipment (DTE) and Data
Circuit-terminating Equipment (DCE) for terminals operating in the packet mode and connected
to public data networks by dedicated circuit, available at
http://www.itu.int/publications/index.html.
9. ITU-T T.30 Recommendation: Procedures for document facsimile transmission in the general switched telephone network, available at http://www.itu.int/publications/index.html.
The MMA955xL three-axis accelerometer is a member of Freescale’ s Xtrinsic family of intelligent sensor
platforms. This device incorporates dedicated accelerometer MEMS transducers, signal conditioning, data
conversion and a 32-bit, programmable microcontroller.
This unique blend transforms Freescale’s MMA955xL devi ce into an intelligent, high-precision
motion-sensing platform able to manage multiple sensor inputs and make system-level decisions required
for sophisticated applications such as gesture recognition, tilt computation, and pedometer functionality.
The MMA955xL platform is programmed and configured with CodeWarrior Development Studio
software. This integrated-design environment enables customers to quickly and easily shape and
implement custom algorithms and features to exactly match their application needs.
Using its master I2C module, the MMA955xL platform can manage secondary sensors such as pressure
sensors, magnetometers or gyroscopes. This allows sensor initialization, calibration, data compensation
and computation functions to be off-loaded from the system application processor . Multiple sensor inputs
can be easily consolidated by the MMA955xL device which acts as an intelligent sensing hub and highly
configurable decision engine. T otal system power consumption is significantly r educed as the application
processor stays powered down until absolutely needed.
•Three accelerometer operating ranges:
— ±2g: Suits most user-interaction (mouse) motions and free fall
— ±4g: Covers most regular human dynamics (walking, jogging)
— ±8g: Detects most abrupt activities (gaming)
•Integrated temperature sensor
•One slave SPI or I2C interface operates up to 2 MHz dedicated to communication with host
processor
•One master I2C interface operates up to 400 kbps used to communicate with external sensors
•10, 12, 14 and 16-bit ADC trimmed data formats available.
•1.8V Supply voltage
•32-bit ColdFire V1 CPU
•Extensive set of power management features and low power modes.
•ROM-based flash controller and slave port command line interpreter
•Two channel timer with input capture, output capture or edge-aligned PWM
•Programmable delay block for scheduling events relative to start of frame
•Modulo timer for scheduling periodic events
2.2Software features
This device may be programmed to provide any of the following:
•Orientation detection (portrait/landscape)
•High-g/low-g threshold detection
•Pulse detection (single, double and directional tap)
•Auto wake/sleep
•Linear and rotational free fall
•Flick detection
•Embedded smart FIFO
•Power management
•Pedometer
•Shock, vibration and sudden-motion detection
•Tilt-angle computation
The association of a high-performance accelerometer with a powerful, embedded ColdFire V1 MCU core
gives the possibility to grow and customize this list in an unprecedented way.
This low-power intelligent sensor is optimized for use in portable and mobile consumer products such as:
•Mobile phones/PMPs/PDAs/digital cameras
— Orientation detection (portrait/landscape)
— Image stability
— Tilt control enabled with higher resolution
— Gesture recognition
— Tap to control
— Auto Wake/Sleep for low power consumption
•Smartbooks/eReaders/netbooks/laptops
— Anti-theft
— Freefall detection for Hard Disk Drives
— Orientation Detection
— Tap Detection
•Pedometers
•Gaming and toys
•Personal navigation devices (PNDs)
•Public transportation ticketing systems
•Activity monitoring in medical applications
•Security
— Anti-theft
— Shock detection
—Tilt
•Fleet monitoring, tracking
— Dead reckoning
— System auto wake-up on movement
— Detection
— Shock recording
— Anti-theft
•Power tools and small appliances
—Tilt
— Safety shutoff
The package pinout for this device provides a superset of functions found on competitive devices, as well
as other Freescale accelerator devices. All pins on the device are utilized and many pins have multiple
possible uses.
Users may select from multiple pin functions via the SIM pin mux-control registers. (See “Pin Mux
Table 3-1 summarizes functional options for each of the device’s pins.
Table 3-1. Pin functions
Pin #Pin function #1
1V
2BKGD/MSRGPIO9Background debug/mo de select RGPIO9
3RESETB
4SCL0RGPIO0SCLK
5V
6SDA0RGPIO1SDISerial data for slave I2C/RGPIO1/SPI serial data input
7RGPIO2SCL1SDORGPIO2/Serial clock for master I2C/SPI serial data output
3
8
RGPIO3SDA1SSBRGPIO3/Serial data for master I2C/SPI slave select
9RGPIO4INTRGPIO4/Interrupt input
10RESERVED (Connect to VSS)Must be connected to GND externally
11RGPIO5PDB_AINT_ORGPIO5/PDB_A/INT_O slave port interrupt output
12RGPIO6AN0TPMCH0RGPIO6/ADC Input 0 / TPM Channel 0
13RGPIO7AN1TPMCH1RGPIO7/ADC Input 1 / TPM Channel 1
14V
15RGPIO8PDB_BRGPIO8/PDB_B
16V
1
Pin Function 1 represents the reset state of the device. Pin functions may be changed via the SIM pin mux-control
registers (“Pin Mux Control Register0”).
2
RESETB is an open-drain, bidirectional pin. By default, the output function is not on.
3
RGPIO3/SDA1/SSB = LOW at startup indicates that SPI should be used as slave instead of the I2C module.
1
Pin function #2Pin function #3Description
DD
2
Digital power supply
Active low reset
Serial clock for slave I2C/RGPIO0/Serial clock for slave
The following sections provide descriptions of the various pin functions available on the MMA955xL
devices. T en of the device pins are multiplexed with Rapid GPIO (RGPIO) functions. (See “Rapid GPIO”
on page 239.) The “Primary Pin Function #1” column of Table 3-1 lists the functions that are active when
the device exits the reset state. The pin mux control registers in the System Integration Module (or SIM)
can be used to change pin assignments for these pins after reset. (See “System Integration Module” on
page 189.)
3.2.1VDD and V
SS
These are the digital power and ground pins and must be connected to the same voltage. VDD is nominally
1.8V for this device.
3.2.2V
These are the analog-power and ground pins. V
to remove any digital noise that may be present on the supply . V
DDA
and V
SSA
is nominally 1.8V for this device and must be filtered
DDA
is usually connected to VDD through
DDA
an appropriate filtering network.
3.2.3RESETB
The RESETB pin is an open-drain, bidirectional pin with an internal weak pull-up resistor . At power-up,
it is configured strictly as an input pin. Setting RCSR[DR] (Reset Control and Status Register “Drive
Reset” bit) to 1 will cause the RESET function to become bidirectional. (See “Reset Control and Status
Register” on page 201.) Using this feature, the MMA955xL platform can reset external devices whenever
it is reset for any purpose other than power-on-reset.
3.2.4Slave I2C: SDA0 and SCL0
These are the slave I2C data and clock signals, respectively . The MMA955xL platform may be controlled
via this serial port or through the slave SPI interface.
State at reset: Open-drain, bidirectional in input mode, pull-up resistor disabled.
3.2.5Master I2C: SDA1 and SCL1
These are the master I2C clock and data signals, respectively . Because th e MMA955xL device contains a
32-bit ColdFire V1 CPU, it is fully capable of mastering other devices in the system via this serial port.
(For details, see “Inter-Integrated Circuit” on page 153.) This allows the MMA955xL platform to off-load
certain tasks from the main CPU, allowing it to conserve power by entering sleep mode. The MMA955xL
device can then issue a wake-up interrupt to the main CPU when motion is detected by the on-chip
transducer or when a slave device (such as pressure sensor or magnetometer) flags that activity has
occurred.
State at r eset: Inactive. SDA1 and SCL1 are secondary functions on RGPIO[3:2], which owns the pins at
reset.
The on-chip ADC can be used to perform a differential, analog-to-digital conversion based on the voltage
present across pins AN0(-) and AN1(+). Conversions on these pins are subject to the same output data rate
(ODR) rules as the MEMS transducer signals.
State at reset: Inactive. AN[1:0] are secondary functions on RGPIO[7:6], which owns the pins at reset.
3.2.7Rapid General-Purpose I/O: RGPIO[9:0]
The ColdFire V1 CPU has a feature called “Rapid GPIO” (RGPIO). This is a 16-bit input/output port with
single-cycle write, set, clear and toggle functions available to the CPU. The MMA955xL platform brings
out the lower 10 bits of that port as pins of the device.
State at reset:
•RGPIO[9]: Inactive. BKGD/MS owns the pin at reset.
•RGPIO[8:2]: Pin mux registers for these bits are configured as RGPIO. Pull-ups are disabled.
RGPIO functionality can be enabled via RGPIO_ENB[8:2].
•RGPIO[1:0]: Inactive. SDA0 and SCL0 own the pin at reset.
3.2.8Interrupts: INT
This input pin may be used to wake the CPU from a deep-sleep mode. It can be programmed to trigger on
either rising or falling edge or high or low level. This pin operates as a level-7 (high-priority) interrupt.
State at reset: Inactive. RGPIO[4] owns the pin at reset.
3.2.9Debug/mode control: BKGD/MS
At power-up, this pin operates as Mode Select. If low during power-up, the CPU will boot into debug halt
mode. If high, the CPU will boot normally and run code.
After power-on reset, this pin can operate as a bidirectional, single-wire background debug port. It can be
used by development tools for downloading code into on-chip RAM and flash and to debug code.
State at reset: Mode Select (MS).
•MS = 0 at exit from reset => Boot to debug halt mode
•MS = 1 at exit from reset => Boot to run mode
State after reset: BKGD. The BKGD pin is a bidirectional, pseudo-open-drain pin used for
communications with a debug environment. For additional details, see “Version 1 ColdFire Debug” on
These are the two outputs of the programmable delay block described in “Programmable Delay Block” on
page 221. Normally, the PDB is used to schedule internal events at some fixed interval(s) with respect to
the start of either an analog or digital phase. By bringing the PDB outputs to these pins, it becomes possible
for the MMA955xL device to initiate some external event, also with respect to start of analog or digital
phase.
3.2.11Slave SPI interface: SCLK, SDI, SDO and SSB
These are the slave SPI clock, data in, data out and slave select signals, respectively. The MMA955xL
platform may be controlled via this serial port or via the slave I2C interface.
State at reset: In reset, these pins are configured as per I2C and RGPIO[3:2] functions listed above. The
pin may be reconfigured for SPI use as part of the boot process.
Figure 3-3 shows an example of the complete system connections when the MMA955xL platform is used
as a smart-accelerometer, slave peripheral to a host processor.
All that are required to attach the MMA955xL device to a master CPU are I2C termination resistors, a
ferrite bead and a few bypass capacitors. Optionally, the RGPIO pins can be programmed to generate
interrupts in order to wake the master CPU, as required by any changes in the inertial input. In the latter
case, the interrupts should be routed to the external interrupt input pins of the master CPU.
Figure 3-3 includes the background debug header connections as well as a manual reset push button.
Figure 3-3. Platform as a slave with BDM header and reset button
Figure 3-4 shows an example of the system connections when the MMA955xL platform is used as an
autonomous sensor hub. This type of connection increases the overall system efficiency as the various
sensors are handled directly by the MMA955xL device, through its master I²C bus and analog inputs.
In such a sensor-hub configuration, the MMA955xL platform processes and fuses the sensors’ data before
transferring it to the host platform, so that data is refined as higher-level information. The master CPU can
go into Sleep mode as the MMA955xL device will issue a wake-up request should any external event
require the CPU’s attention. The RGPIO8 pin (Pin 15) is typically used for wake-up requests.
Figure 3-4. Platform as a sensor hub
3.3.3Power
An internal circuit powered by V
order for this signal to be properly recognized, it is important that VDD is powered up before, or
simultaneously with, V
The voltage potential difference between VDD and V
accomplish this is to power both pins from the same voltage source.
When using the same voltage source, some digital noise might reach the analog section. To prevent this,
connect a small inductor or ferrite bead in serial with both the VDDA and VSSA traces. Additionally , two
provides the MMA955xL platform with a power-on-reset signal. In
DDA
.
DDA
must not exceed 0.1V. The simplest way to
DDA
Pins and Connections
ceramic capacitors (of approximately 1 µF, + 0.1 µF) can be used to efficiently bypass the power and
ground of both digital and analog supply rails.
3.3.4 RESETB pin
Figure 3-3 on page 31 illustrates an exhaustive arrangement where a Reset event can be generated by:
•An external, manual reset button
•The Background Debug Mode interface
•The VDD main supply
An external, pull-up resistor is necessary to reduce and better control the RESETB voltage-settling time.
An optional shunt capacitor to ground can be added to that node in order to reduce EMC and noise
susceptibility. With the shunt capacitor, the maximum RC time constant has to be strictly bounded. (For
details, see “System Integration Module” on page 189.)
At power-up, the RESETB pin is configured as an input pin, but it also can be programmed as
bidirectional. Using the bidirectional feature, the MMA955xL platform can reset external devices for any
purpose other than power-on-reset. When using the RESETB pin output drive capability, the allowed
upper limit for the RC time constant is reduced to only micro-seconds.
3.3.5Background / mode select (BKGD/MS)
Figure 3-3 on page 31 depicts the connection to the BKGD/MS pin when in-circuit debug capability is
desired.
In this configuration, the background header also takes control of the RESETB line. This could result in
parasitic capacitance from the BDM connector and its ribbon cable that may increase RESETB settling
time. This situation must be considered in the user’s implementation.
Chapter 4Operational Phases and Modes of Operation
4.1Modes of operation
The V1 ColdFire core supports RUN, HALT, RESET and ST OP modes natively . These are present on any
ColdFire-based product. The MCU integration adds additional controls to STOP mode, effectively
creating three modes where one existed previously.
The set of modes then becomes:
RUNThe CPU executes instructions in this mode that can be further subdivided into
User and Supervisor modes.
HALTVersion 1 ColdFire Core HALT/DEBUG mode
RESETReset asserted. Circuitry in default state. RESET can be divided into several
phases of operation. For details, see “System Integration Module” on page 189.
STOP
STOP
STOP
FC
SC
NC
STOP – Clock in Fast Mode – Nominally used for A (See “Overview” on
page 35.)
STOP – Clock in Low Speed Mode – Nominally used for I (See “Overview” on
page 35.)
STOP – No clocks – All clocks disabled. Nominally used for the SLEEP phase.
4.2Frame structure
In addition to the modes above, the MMA955xL platform is designed to facilitate a “frame-based”
software scheduler. Analog sensor conversions are best executed when the CPU is quiet and there may be
times when both AFE and CPU are dormant. The MMA955xL device includes hardware mechanisms to
make it easy to schedule these different functions.
4.3Overview
The MMA955xL platform can be programmed to take a continuous sequence of evenly spaced samples
over time. This section specifies the terms for timing and phases. Figure 4-1 on page 36, Figure 4-2 on
page 36 and Figure 4-3 on page 36 illustrate a number of these terms that will be subsequently defined.
Timing is defined in terms of “frames.” There are two types of frames: Sample and non-sample. Sample
frames include an analog phase in which sensor outputs are sampled. Non-sample frames simply omit the
analog phase.
Output Data Rate (ODR), Frame Rate (FR) and Sample Data Rate (SDR) are three important terms that
will be used throughout the following text.
One “bucket” of
samples has been
converted to raw
digital form.
Digital processing
completed. Slave
registers have been
updated.
First non-sample frameSecond non-sample frameThird non-sample frame
D
D
I
D
I
t
D
t
I
Digital processing completed.
tF = FR
-1
First sample frameNon-sample frameSecond sample frame
A
D
D
I
D
I
A
The ODR specifies the rate at which an application reads sensor data from the device. The actual SDR is
ODR x OSR, where the integer Over Sample Ratio (OSR) is typically in the range of 1 to 4. As a result,
several sample frames might be required to support a single sensor reading by the application.
Additionally, non-sample frames, may be intermixed with sample frames.
Frame Rate (FR)This is the basic unit of time from which all other events are timed.
Output Data Rate (ODR)The rate at which the MMA955xL platform provides conversion data to the
user for a given quantity. This will be SDR/OSR.
Over-Sample Ratio (OSR) The MMA955xL device can support on-chip filtering of sensor data. The
over-sample ratio specifies how many sample frames are required to support
a specified output data rate using a desired filtering algorithm.
A
Analog phase – All analog (C2V and ADC) processing occurs here.
Depending on configuration data, the analog subsystem may have processed
samples for three dimensions of acceleration and a single auxiliary parameter,
during each A interval. The auxiliary parameters available include
temperature and the external ADC inputs. The CPU and associated peripherals
are normally “quiet” during this mode.
D
Digital phase – The CPU and peripherals are active, analog in low-power
state. Digital filtering and processing of the converted ADC values occurs
here. The length of this phase will vary depending upon the CPU load. It
cannot exceed (tF - tA) for sample frames.
I
Inactive or Idle phase – Most of the device is powered down for minimal
power consumption. This phase is of variable length (tF - tA - tD), where tF is
fixed, tA is determined by the analog front end (AFE) and tD varies depending
on CPU loading.
Sample FrameSample frames correspond, one-to-one, for each “sample” of data.
Sample Data Rate (SDR)The rate at which the MMA955xL device requires raw conversion data from
its sensors and converters. If the device is configured for additional
over-sampling, this may be some integer times the output data rate or ODR.
One sample frame = SDR-1 seconds.
t
A
t
D
t
I
Length of A
Length of D
Length of I – The idle phase. This may approach zero, depending on CPU
Additional terms that occasionally factor into the discussions include:
F
osc-high
F
osc-low
P
osc-high
P
osc-low
The high-speed frequency of the on-chip oscillator. This is nominally 8 MHz.
The low-speed frequency of the on-chip oscillator . This is nominally F
osc-high
The length of time required for one cycle of the oscillator clock in high-speed
mode (= 1/F
osc-high
).
The length of time required for one cycle of the oscillator clock in low-speed mode
(= 1/F
osc-low
= 128/F
osc-high
).
4.3.3Phase triggers
Figure 11-1 on page 190 illustrates some of the major interactions between modules in this device:
•The “start-of-frame” signal is generated by the frame interval counter.
•SIM hardware is responsible for generating phase triggers for A and D.
•The “End A” signal is generated by the AFE.
•In sample frames, “Start A” results from the start-of-frame from the CLKGEN module. In this
case, “Start D” results from the “End A” signal.
•For non-sample frames, the “start-of-frame” results in “start D”.
•“A started” and “D started” signals (not shown) can be slightly delayed from “start A” and
“start D”. In the event that the system clock is switching from off (or low speed) to high speed,
these signals are not asserted until the oscillator actually switches. The difference in the two sets
of triggers is any latency associated with interrupt assertion and/or CLKGEN-mode switching.
/128.
Figure 4-4 illustrates sequencing of the “Start A“and “Start ” hardware triggers. Figure 4-5 on page 39
shows that a STOP instruction (with STOPCR[SC] = 1) is required to transition into the idle phase. (See
the SIM register map.)
frame. An output data frame is one
or more sample frames in length,
depending on the amount of oversampling being done.
w
r
i
t
e
OS
C
T
R
L
Wake on external interrupt or
slave I
2
C command received.
Processor executes STOP
prior to “start data frame.”
Software
Overrun
Condition
Start data frame
4.4Clock operation as a function of mode/phase
Figure 4-6 illustrates the nominal phases of operation for this device. The values of A, D and I were
discussed briefly in “Frame structure” on page 35. The reset operation is described in “Reset generation”
on page 191. The sleep phase is defined as the device oscillator being off and all circuitry in its lowest
power state.
“Power control modes of operation” on page 42 maps these phases into modes of operation of the Version
1 Coldfire CPU.
There is a strong software component to the application phases diagrammed here. They may be rearranged
from time to time depending on the tasks assigned to the sensor. Tasks scheduling will be handled by the
Scheduler Application (ID 0x01) as described in the MMA955xL Intelligent, Motion-Sensing Platform Software Reference Manual (MMA955XLSWRM).
Figure 4-6. Operational phases
The phases shown above have distinct characteristics with regard to clock operation. These are outlined in
Table 4-1. The operation of clock-gating registers (PCERUNx, PCESSCx and PCESFCx) in the SIM do
not change as a result of debug operation, only the oscillator operation.
The ENBDM bit in the Version 1 ColdFire Extended Configuration/Status Register (XCSR) is set to “1” to enable BDM
OFF, oscillator in
Low-Speed Mode
Oscillator in
)
shutdown
High Speed
High Speed
OFF, oscillator in
Low-peed Mode
Oscillator in
shutdown
High Sp ee d
High Sp ee d
communications. The CPU is clocked even during STOP modes. Frequency-hopping is disabled in Debug mode, as BDM
communications require a constant clock rate for proper operation.
The Version 1 ColdFire architecture incorporates several modes of operation. These include Reset, Run,
Stop and Halt (debug). A, I and Sleep phases in Figure 4-6 are all mapped into the ColdFire STOP mode
on this device. The CPU has only a single view of STOP operation, but at the device level, additional levels
of distinction have been added:
STOP
STOP
STOP
FC
SC
NC
STOP – Clock in Fast Mode. Nominally used for A.
STOP – Clock in Low Speed Mode. Nominally used for I.
STOP – All clocks disabled. Nominally used for the SLEEP phase.
Boot and D are functionally identical and map into the Run mode. Figure 4-7 adds HALT mode to the
set and remaps the collection as a full-state transition diagram, including debug modes. Table 4-2
summarizes the triggers that cause transitions from one mode to the next.
Figure 4-7. Allowable state transitions
Transition #FromToTrigger
1
RUNSTOP
STOP
SC
RUNAny interrupt
Table 4-2. State transitions
XCSR[ENBDM] = 0, STOPCR[SC] = 1; followed by STOP instruction
The left-most map in Table 5-1 is the generic, high-level, memory map applicable to the V1 ColdFire
family . Memory map areas shown for RAM, ROM and flash are a superset for the family. Lesser amounts
of all three will usually be included on specific devices. The memory map for the MMA955xL platform
is shown on the right.
The slave peripherals section of the memory map is further broken down as shown in Table 5-2.
MMA955xL microcontrollers include off-platform, 8-bit and 16-bit peripheral buses. The bus bridges
from the ColdFire system bus to off-platform buses are capable of serializing 32-bit accesses into two
16-bit accesses or four 8-bit accesses. This can be used to speed access to properly aligned peripheral
registers. Not all peripheral registers are aligned to take advantage of this feature.
The off-platform 8- and 16-bit interfaces operate at the same speed as the CPU.
CPU accesses to those parts of the memory map marked as “Unimplemented” in Table 5-1 result in an
illegal address reset if CPUCR[ARD] = 0 or an address error exception if CPUCR[ARD] = 1.
The lower 32 KB of flash memory (16 KB in the MMA955xL platform) and slave peripherals section of
the memory map are most efficiently accessed using the ColdFire absolute, short-addressing mode. RAM
is most efficiently accessed using the A5-relative addressing mode (address register indirect with
displacement mode).
5.2Alignment issues
ColdFire has a big endian byte addressable memory architecture, so the most-significant byte of each
address is the lowest-numbered one, as shown in the following figure. Multi-byte operands (such as 16-bit
words and 32-bit-long words) are referenced using an address pointing to the most-significant (first) byte.
Regions within the memory map are subject to restrictions with regard to the types of CPU accesses
allowed. These are outlined in Table 5-3. Non-supported access types terminate the bus cycle with an error
and would typically generate a system reset in response to the error termination.
Allowed access types are peripheral-specific. The peripheral bus bridge will serialize 16- and 32-bit accesses into multiple
8-bit accesses. When using 8-bit peripherals, care must be taken to ensure that all accesses are properly aligned and only
desired 8-bit locations are accessed.
2
Allowed access types are peripheral-specific. The peripheral bus bridge will serialize 32-bit accesses into multiple 16 -bit
accesses. When using 16-bit peripherals, care must be taken to ensure that all accesses are properly aligned and only desired
16-bit locations are accessed.
The CF1_INTC register map is sparsely populated, but retains compatibility with earlier ColdFire
interrupt-controller definitions. The CF1_INTC occupies the upper 64 bytes of the 4-GB address space
and all memory locations are accessed as 8-bit (byte) operands. This 64-byte space includes the
program-visible interrupt controller registers as well as the space used for interrupt-acknowledge (IACK)
cycles.
Table 5-15 is a summary of CF1_INTC user -accessible peripheral registers and control bits. Cells that are
not associated with named bits are shaded. A shaded cell with a 0 indicates this unused bit is always read
as a 0. Shaded cells with dashes indicate unused or reserved bit locations that could be read as 1s or 0s.
When writing to these bits, write a 0 unless otherwise specified.
5.3.2Nonvolatile register area
There is a nonvolatile register area consisting of a block of 4 bytes in flash memory at
0x(00)00_3FFB–0x(00)00_3FFF . The byte at 0x(00)00_3FFF is allocated to flash protection and security
functions. Additionally, the byte at 0x(00)00_3FFE is used to initialize boot options for the device. See
“Security” on page 69 for further details on both topics.
Because the nonvolatile register locations are flash memory, they must be erased and programmed like
other flash memory locations.
5.3.3RGPIO
The section of memory at 0x(00)C0_0000 is assigned for use by the ColdFire Rapid GPIO module. See
Table 5-4 for the Rapid GPIO memory map and Chapter 15, “Rapid GPIO” for further details on the
For details of the Interrupt-Controller operation, see Chapter 19, “Interrupt Controller”. Table 5-16
summarizes the default vector map for this device.
Error exceptions arising from user-mode attempts to access supervisor-only memory and registers will
result in a soft-reset of the device being performed by the “access error” exception handler specified at
Vector #2 of the exception table.
5.6RAM
This microcontroller includes 2 KB of static RAM. RAM is most efficiently accessed using the A5-relative
addressing mode (address register indirect with displacement mode). Any single bit in this area can be
accessed with the bit manipulation instructions (such as BCLR and BSET).
At power-on, the contents of RAM are uninitialized. RAM data is unaffected by any reset provided that
the supply voltage does not drop below the minimum value for RAM retention (V
Flash controller registers are available only from Supervisor mode. User
access to flash functions is encapsulated via a set of ROM routines. The
flash array can only be written in Supervisor mode. Violations to this, as
well as the restrictions above, will result in an access-error exception.
6.1.1Overview
The main flash memory array is intended primarily for program storage. In-circuit programming allows
the operating program to be loaded into the flash memory after final assembly of the application product.
It is possible to program the entire array through the single-wire, background-debug interface.
Flash address and data values are communicated over system busses. Flash controls are managed via
registers mapped onto the IP-bus space. User access to program/erase functions is via dedicated ROM
function calls. Direct access to flash controller registers is disallowed.
6.1.2Features
Features of the on-chip flash memory include:
•4K-deep by 32-bit main array (16 KB total)
•Page erase size = 512 bytes
•Security lockout
•Protection against accidental programming/erase operations
•Program, erase and mass-erase procedures can be performed using pre-programmed ROM
routines.
6.2Theory of operation
Flash memory is nonvolatile and is ideal for single-supply applications allowing for field reprogramming
with no need for external, high-voltage sources for programming or erase operations. Contents are retained
for an extended period of time over 100 years under nominal conditions.
Contents of flash memory can be read randomly, just like RAM. Array read-access time is one bus cycle
for bytes, aligned words and aligned double-words. Unlike random access memory, flash memory cannot
simply be written with a desired value. It must first be “erased” and “programmed.” For flash memory , an
erased bit reads 1 and a programmed bit reads 0. Once programmed to 0, a bit cell remains in that state
until erased again. A bit cell cannot be “programmed” to change from 0 to 1.
It is not possible to read from flash memory while it is being erased or programmed.
Bit cells can be erased/programmed a finite number of times before data integrity issues begin to occur.
Nevertheless minimum number of erase/program cycles can exceed 20,000 under nominal conditions.
NOTE
A flash block address must be in the erased state before being programmed.
Cumulative programming of bits within a flash block address is not allowed
except for status field updates required in EEPROM emulation applications.
The flash hard block has a number of control signals associated with programming and erase operations.
These must be sequenced over time and in a specified manner in order to erase and subsequently program
flash memory . Internally generated, high voltages are a pplied for specific periods of time which must not
be exceeded.
The hardware wrapper for flash memory provides rudimentary interlocks and safeguards, as well as some
strobe generation. Higher-level intelligence is provided via canned ROM routines for basic flash
operations.
All program erase operations must be performed using ROM routines executed while the CPU is in
Supervisor mode. A special trap function (call_trap) is supplied which places the CPU in the Supervisor
state, calls the appropriate ROM routine and then returns to User mode. For additional details, see
“User-callable ROM functions”, “RMF_FLASH_PROGRAM” and “RMF_FLASH_ERASE”.
Any attempt to directly write any flash controller registers in normal mode of operation will result in
generation of an access-error exception.
6.3Modes of operation
There are four user modes of operation for the flash controller: IDLE, READ, PROGRAM and ERASE.
PROGRAM and ERASE modes will only be reached while CPU is in Supervisor state.
6.3.1Flash IDLE
Whenever the flash is not accessed by the CPU, including during WAIT and STOP modes, it will be in this
IDLE mode. The flash module will be in standby and consume minimal power.
6.3.2Flash READ
The flash will be in READ mode when it is read by the CPU. However, when the flash is in either
PROGRAM or ERASE mode, the flash module cannot be read. Any attempt to read data from flash will
return undefined data.
6.3.3Flash PROGRAM
In this mode, the flash array can be programmed 32 bits at a time. Individual data bits can be programmed
from 1 to 0, but not from 0 to 1.
6.3.4Flash ERASE
Flash memory can be erased one page (512 bytes) at a time or the entire main array can be erased in one
mass-erase action.
The erase state of all data bits in the array is 1.
The flash module is partitioned into two spaces in memory . The firs t is the array memory which contains
the main flash array . The second area allows supervisor access to module registers and is mapped into the
16-bit, IP-bus space. User access to the flash controller is via dedicated ROM functions. Direct user access
to the controller register set is prohibited.
6.4.1Array memory map
The main flash array is designed to support 16 KB of general program storage. Four bytes of this are
reserved for use in storing non-volatile parameters.
Table 6-1. Flash array memory map
Address rangeFunction
(00) 00_0000 – (00) 00_3FFB
16380 (16K - 4) bytes
(00) 00_3FFC – (00) 00_3FFF
4 bytes
Reserved for nonvolatile options (4 bytes)
FOPT[7:0] is loaded from address 0x3FFF during each reset sequence.
General storage
The boot-to-flash flag (FOPT[FB]) is set to the inverse of Bit 5 of addr ess 0x3FFE during the ROM
boot process on power-on-r eset. Thus, if Bit 5 of 0x3FFE is set to “1,” the device will not boot to flash.
As a consequence, a virgin device with erased flash will boot directly into the ROM command interpreter
on power-up.
Similarly, the FOPT[9:8] bits are loaded from bits [1:0] of 0x3FFE during the POR boot sequence by the
ROM bootloader.
The last word of the flash array (at $3FFC) is reserved and should not be used by the application program.
The least-significant byte of this location ($3FFF) is referred to as NVOP T . It contains bits that define flash
security and write-protection levels.
Table 6-2. Reserved locations in the main array
0x3FFC0x3FFD0x3FFE0x3FFF
IdentifierCRC[15:8]CRC[7:0]NVBOPTNVOPT
Used for
Expected CRC to be computed
over 0x0000 to 0x3FFB
FOPT[15:8]
The boot-to-flash flag (FOPT[FB]) is set to the
inverse of Bit 5 of address 0x3FFE during the ROM
boot process on power-on-reset.
FOPT[10:8] are loaded from bits 2:0 of 0x3FFE
during the ROM sequence.
FOPT[7:0]
FOPT[7:0] is loaded
with NVOPT byte at
reset.
The second least-significant byte of this location ($3FFE) is referred to as NVBOPT. It contains control
bits that define whether or not a CRC check is run at boot time and whether the device boots to flash or
not. Finally, the 16-bit CRC value is stored at 0x3FFC.
Flash control registers are not available directly from User mode. Nevertheless, the FOP T register will be
altered during POR and reset with the content of the upper two bytes of the main flash array. Flash
functions can only be accessed via the ROM routines described in Chapter 7, “ROM”.
FOPT[7:0] is loaded from the last byte of the main array (NVOPT) during the reset sequence. Therefore
all modifications to FOP T[7:0] are lost at the next reset. Permanent changes to FOP T[7:0] can only be done
by modifying the flash data stored at NVOPT.
To change the value in this register, erase and reprogram the NVOPT location in flash memory as usual
and then issue a new MCU reset.
FOPT can only be read or modified when the CPU is in Supervisor mode.
1514131211109876543210
ReadReserved
Write000
Reset0000000011111110
= Unimplemented or Reserved
BF
Rsv’d0
CHECKB
MECFB
11
PW
1
SSWSSC
PROTB
Figure 6-2. Flash Options register (FOPT)
Table 6-4. Flash Options register (FOPT) field descriptions
Bit(s)FieldDescription
15:14—
13BF
12—
Reserved
Always write as “00.”
Boot from Flash
This is a simple R/W bit in the flash controller. This bit is initialized to the inverse of Bit 5 of flash location
0x3FFE by the boot ROM on power-up. It is read by the ROM code in a later step of the reset process.
The code value affects where control is ultimately transferred.
0 Do not boot from flash.
1 Boot from flash on next reset.
Table 6-4. Flash Options register (FOPT) field descriptions (continued)
Bit(s)FieldDescription
Mass Erase on CRC Failure
A control bit for the ROM boot function. It is only applicable if CHECKB = 01 or 10. In those cases, if
the CRC check fails and MECF=0, then the user portion of the flash memory will be erased.
This bit provides additional protection of customer code from hacker attempts to bypass security via
10MECFB
9:8CHECKB
7:6—Reserved
“interrupted” erase operations.
This bit is initialized to Bit 2 of flash location 0x3FFE by the boot ROM on power-up. It is read by the
ROM code in a later step of the reset process.
1 Do nothing.
0 Erase the user portion of the main flash array.
Perform Flash Checksum
A control bit for the ROM boot function. It controls whether or not a flash checksum is computed and
checked against expected results before transferring control to code executing in flash. This field is
loaded from location 0x3FFE by the ROM bootloader on POR only. It can be modified via software and
will affect operation during subsequent non-power-on reset sequences.
00 Do not perform checksum.
01 Perform checksum on POR only.
10 Perform checksum on any reset.
11 Do not perform checksum.
Flash Memory Controller
PROTB Writeable
5PW
4PROTB
3—Reserved
2SSW
1:0SSC
The PROTB bit can be written from software only when PW = 1. If PW = 0, it must first be reset to 1
before PROTB can be modified.
Active Low Write Protect
Used to inhibit programming and erase operations.
This bit can only be written when PW = 1.
0 Array is protected from unintentional program/erase operations.
1 Array is not protected from unintentional program/erase operations.
Security State Wr iteable
The SSC bit field can be written from software only when SSW = 1. If SSW = 0, it must first be reset to
one before SSC can be modified.
Security State Code
Determine the security state of the MCU. When the MCU is secure, the contents of flash memory
cannot be accessed by instructions from any unsecure source including the background debug
interface.
These bits can only be written when SSW = 1. Security can be temporarily cleared by setting these bits
to 11, however , they will be re-initialized from NVOPT on every reset. These bits are initialized from bits
1:0 of flash location 0x3FFF during each reset sequence.
These bits are initialized to 10 (Secure) by when the peripheral reset is asserted. The flash wrapper will
almost immediate overwrite them as the module exits reset.
00 Unsecured
01 Unsecured
10 SECURE
11 Unsecured
Devices are usually shipped with the lower portion of flash memory pre programmed with a sensor
scheduler, trim algorithms and basic sensor functions included. The upper portion of the flash memory is
normally shipped in an erased condition.
6.7.2End user
The flash module can be read after the device has completed the reset ope ra tion. No s pecial initialization
procedure is required to initialize the module.
FOPT[7:0] is automatically loaded from NVOPT ($3FFF) during any reset sequence.
A user program may need to be programmed to the flash module before the device can be used in the
targeted application. The following sections describe the programming and erase operation of the flash
module.
In order to facilitate user, flash-area erase and program operations, Freescale will provide with the
MMA955xL platform evaluation kit appropriate abstraction tools that will isolate the end user from the
ROM routines.
6.8Programming model
All user access to the flash controller is via Freescale supplied ROM routines which are described in
“ROM” on page 71. Please note that interrupts are disabled when these functions execute and STOP mode
operation is temporarily disabled. System clocks will remain in their high-speed states (16 MHz) during
these operations.
For details of the ROM function for flash programming, see “RMF_FLASH_PROGRAM” on page 105.
For details of the ROM function for flash erase, see “RMF_FLASH_ERASE” on page 108.
The user can control the state of the FOPT[PROTB] bit via RMF_FLASH_PROTECT and
RMF_FLASH_UNPROTECT. (See “RMF_FLASH_PROTECT and RMF_FLASH_UNPROTECT” on
page 111.)
Security can be temporarily suspended via RMF_FLASH_UNSECURE (See
This family of devices include circuitry to prevent unauthorized access to the contents of flash memory.
When security is engaged, BDM control/communication with the CPU is extremely limited. Read/Write
access via BDM is then limited to XCSR[31–24], CSR2[31–24].
It is possible to check STOP/HALT status of the CPU, enable BDM clocks, configure reset behavior and
assert reset.
Table 6-5. CPU resources available via BDM In Secure mode
RegisterFieldAccessFunction
XCSR[31]CPU_HALTR1, if CPU is Halted
XCSR[30]CPU_STOPR1, if CPU is in STOP mode
XCSR[29:27]CSTATRBDM Command Status
XCSR[26]CLKSWR/WBDM Clock Select (no function on the device)
XCSR[25]SECR/WSecurity Status (1 = Secured)
XCSR[24]ENBDMR/WEnable BDM (1 = BDM is enabled)
CSR2[31]PSTBPRPST Buffer Stop
CSR2[30]RESERVEDN/A
CSR2[29]COPHRR/WCOP halt after reset (no function on the device)
CSR2[28]IOPHRR/WIllegal Operation halt after reset
CSR2[27]IADHRR/WIllegal Address halt after reset
CSR2[26]RESERVEDN/A
CSR2[25]BFHBRR/WBDM force halt on BDM reset
CSR2[24]BDFRWBackground debug force reset
Security is engaged or disengaged based on the state of nonvolatile register bits shown in FOPT[SSC].
During the reset sequence, the contents in bits 7:0 of the nonvolatile location NVOP T ($3FFF) are copied
from flash into bits 7:0 of the working FOPT register. A user engages security by programming the
NVOPT location which can be done at the same time that the flash memory is programmed.
Notice the erased state (SSC = 11b) makes the MCU unsecure. When SSC bits of NVOPT are programmed
to SECURE (10b), the next reset will engage security. In order to permanently disengage security, the
NVOP T bits must be erased. Security can be disengaged by a software interrupt (SWI) that will switch the
MMA955xL platform to Supervisor mode. The SWI should perform the following functions:
1. If necessary, set PROTB = 1b.
2. Mass-erase the flash and verify that the contents have been erased.
When the device boots up to normal operating mode—where MS pin is high
during RESET and SSC programmed to SECURE (10)—flash security is
engaged. In this state, all BDM communication is blocked and background
debugging is not allowed.
There are several classes of functions stored in ROM:
•A boot program, including ROM-based, slave-port command interpreter
•A collection of utilities that can be invoked via the ROM-based slave port interpreter
•ROM functions that are callable from user code using the call_trap() function
ROM code can only be executed when the CPU is in Supervisor mode. Any attempt to access the ROM
while in User mode will result in a privilege violation exception. Error exceptions arising from User-mode
attempts to access Supervisor-only resources will result in a reset of the device.
7.2Boot ROM
The MMA955xL platform boots from a standard routine in ROM. This boot function (shown in
Figure 7-1) is responsible for a number of initialization steps before transferring control to user code in
flash memory. The ROM also contains a simple command interpreter capable of running a number of
utility and test functions for programming and erasing flash memory, as well as a limited set of other
functions.
Individual steps shown in Figure 7-1 are described in more detail in subsequent sections. One common
theme is the use of the Flash Options Register (FOP T). This register is not visible to software operating in
User mode on the ColdFire core. Normally, it is accessed only by supervisor code operating out of the
on-chip ROM.
One of the functions of FOP T is to configure boot options for the device. These are normally fetched once
at power-up from the locations 0x3FFE and 0x3FFF. FOPT bits control the security state of the device,
such as whether or not a mass-erase operation is pending (required to clear device security) and whether
the part is to boot to flash, RAM or the slave-port command interpreter. For a flash boot, the FOPT also
controls whether a checksum is calculated prior to transferring control to flash and determines what is done
if a checksum fails.
Because FOPT[15:8] is initialized only at power-up, it can be manipulated by the slave-port command
interpreter and BDM to reconfigure device operation on subsequent reset operations.
For fielded applications, the normal control flow for the boot function is 1-2-3-4-9. (See Figure 7-1.) Other
options are intended primarily for debug and development purposes.
The choice of I2C or SPI communication is determined by the state of the SSB pin during the boot process.
Low = SPI, High = I
2
C.
7.2.1Boot Step 1: RESET
Any hardware- or software-initiated reset will return the device to this phase. Hardware logic on the chip
is returned to its default state.
During this phase, the FOPT[7:0] (which includes the device’s security state) is reloaded from location
0x3FFF in flash memory . If the reset is a result of a power -on sequence, FOPT[15:8] will be initialized to
all 0s. These register bits are not affected by subsequent reset operations. They are used to coordinate boot
and flash operations across reset sequences.
For Power-on Reset only,
set FOPT[15:8] based on
contents of 0x3FFE
7.2.2Boot Step 2: Load PC and SSP
The Version 1 ColdFire CPU will load the program counter and supervisor-stack pointer from the first two
long-words in ROM. The program execution in ROM begins and start-up code initializes the status register
to 0x2700 and sets the Vector Base Register (VBR) to point to the beginning of ROM (0x300000).
Subsequent to reset, configuration parameters are read from reserved locations in flash and are stored in
specific fields of control registers in the memory map.
For power-up sequences only:
•FOPT[BF] is set to the inverse of Bit 5 of memory location 0x3FFE in flash. This bit controls
whether or not control is transferred to flash in Step 5.
•The FOPT[MECFB,CHECKB] data is loaded from location 0x3FFFE in flash.
Transfer control to the
Slave Port Command Interpreter.
YES
NO
If FOPT[BF]1 has been set, the boot code assumes that the flash is in a programmed state. The boot code
checks FOPT[CHECKB] to determine if a CRC check needs to be run to confirm the flash image. If no
check is needed or a check is run and succeeds, control is transferred to the address specified at location
0x(00)00_0000 in flash memory.
The supervisor stack pointer is re-initialized to the address contained at location 0x(00)00_0004. The
ColdFire Vector Base Register (VBR) is reset to 0x(00)00_0000. If FOP T[FB] has not been set, control is
transferred to Step 5 (Initialize Command Interpreter). If the CRC check fails, and FOP T[MECFB] is set,
the device will be subjected to Mass Erase of User Portion Flash. Control then is transferred to Step 5
(Initialize Command Interpreter). For more details, see “Boot Step 5: Initialize Command Interpreter”.
The “transfer control” block, above, transfers control to code located in flash memory by performing the
following functions:
•Resets the Vector Base Register to 0x(00)00_0000
•Reloads the supervisor stack pointer from the value stored at 0x(00)00_0000 in flash
•Reloads the program counter from location 0x(00)00_0004
Figure 7-4. Boot-to-flash and associated checks (Part 2)
7.2.5Boot Step 5: Initialize Command Interpreter
This step initializes RAM variables and hardware configuration for use by the ROM command interpreter
(Step 6).
The stack pointer is reset on each loop through the command interpreter.
1. This was initialized in Step 3 to the inverse of Bit 5 of flash location 0x(00)00_3FFE.
This function continuously monitors the slave port for commands submitted serially via that port. The
operation is single-threaded.
The port is monitored until a command is entered. An entered command is executed and the interpreter
returns to the monitor loop. If, however, entered commands include a reset command, the state machine
restarts at Step 1.
Commands are submitted and statuses returned via the slave-port mailbox registers. Related details are
provided in “ROM Command Interpreter”.
RGPIO3/SDA1/SSB = LOW at start-up indicates that the SPI should be used as slave instead of I2C. This
is a function of the application boot code, not of the hardware. The boot routine needs to read the RGPIO3
input value and act accordingly.
•PROTB protects against accidental programming/erasures by software running on-chip. It does not
prevent mass-erase via BDM or slave port CI.
•The Page Release Register (PRR) allocates the pages of the flash array to be used by Freescale code
and the user application code. (See “Page-Release Register”.) Pages assigned to Freescale are
protected from accidental erasure and can only be erased under tightly controlled conditions.
•Mass-erase operational requests supply a mask parameter of 0xFFFFFFFF.
•The following resources are restricted to use in Supervisor mode:
— ROM code
— AFE registers
— Flash-controller registers
•Asserting security shuts down almost all access via the BDM and slave ports. The only supported
operations in secure state are RESET, MASS ERASE and GET DEVICE INFO.
ROM
7.3.2Security
Users may secure their code from prying eyes by writing a secure code to NVOP T in the flash array . When
the part is subsequently reset, access to the BDM development port is disabled. In addition, ROM-based,
slave-port access is severely restricted.
Security may be cleared by mass-erasing the device. This can be done via BDM by setting
XCSR[ERASE]1 and resetting the device. The ROM boot code will then erase all application pages (PRR
= 1)2 in flash memory, regardless of the setting of the flash-protection bit (FOPT[PROTB])3.
Security may also be cleared by mass-erasing the part via the slave-port interface. In such cases (as is the
case for software running on-chip), it is necessary first to set FOP T[PROTB] = 1 using the flash-unprotect
function4.
If an attempt is made to read/write any on-chip memory while the device is in a secure state, the
ROM-based, slave-port functions will fail and return a security violation.
1. “Extended Configuration/Status Register” on page 357.
2. “Page-Release Register” on page 78.
3. “Flash Options register” on page 66.
4. “RMF_FLASH_PROTECT and RMF_FLASH_UNPROTECT” on page 111
This section describes generic techniques for managing user access to restricted functions.
The MMA955xL platform is designed to accommodate a varying mix of Freescale and third-party
software. On-chip ROM is dedicated to Freescale use. The flash-memory array can be split between
Freescale and third-party code.
Table 7-1. NVM memory allocations
MemorySizeFreescaleThird-PartyUsage
Boot functions, ROM command interpreter, flash-controller
ROM4 KBX—
Main Flash Array16 KBXX
functions, common utilities. ROM code can be accessed only
when the CPU is in Supervisor mode.
There are 32 512-byte pages of flash memory.
Any of these can be assigned to either Freescale or
third-party use. All content is visible in User mode.
7.4.2Rights-management variables
Non-volatile parameters used for rights management are shown in Table 7-2.
The Device ID provides a relatively unique identifier for any particular device. Freescale does not
guarantee every unit to have a unique number. However, the field will vary from device to device.
7.4.2.2Page-Release Register
As previously mentioned, the main flash array on this device has 32 pages of 512 bytes each. User
programming/erase access to these pages is controlled via a virtual “Page-Release Register” (PRR). The
PRR is dynamically calculated by flash programming/erase firmware routines.
1
PE[31:0]
There is one page-enable (PE) bit in the PRR for each page. If set to “0”, the page is allocated for
Freescale use and will not be made available for customer programming. If set to “1”, the page is available
for customer use. Bit 0 corresponds to the page beginning at address 0x(00)00_0000. Bit 31 corresponds
to the page beginning at 0x(00)00_3E00.
7.4.2.3Hardware restrictions
The flash memory controller contains a non-volatile bit (FOP T[PROTB]) that can be used to protect flash
memory from accidental programming/erase operations.
This bit is sourced from the NVOPT loca tion in flash memory on rese t. It can be temporarily switched in
and out via software. Various mechanism for manipulating this value are described in the descriptions of
the flash-access functions, later in this chapter.
Functions available via the ROM Command Interpreter are summarized in Table 7-3. For a general
overview of the user model associated with these functions, see “Packet transfers and commands
overview” on page 81. Subsequent sections provide the details of the individual functions.
Even on secured devices, it is possible to return the device ID and revision numbers and to change the
flash-protection status. The latter does not waive security at all. Before attempting to mass-erase a secured
device via the ROM command interpreter, however, you must unprotect flash memory.
Most ROM-interpreter functions support transfer of two packets of information. One packet transfer is
from the host to the slave, specifying the command to be executed and any required parameters. The
second transfer is the response packet from the slave. The second transfer is optional in cases where the
response carries only status information.
The Reset command has no return packet.
Mailbox registers on the MMA955xL platform transfer information to and from the command interpreter
via the slave port. The following sections specify the function of each of the mailboxes on a per-command
basis.
Many of the following sections includes one or more examples of how a specific command might be
encoded in the data stream to and from a slave, I2C port. These examples use a consolidated table format
to document I2C bit sequences.
These commands are easily mapped into standard I2C waveforms by noting use of the following notation:
SStart bit/Repeated start
AAcknowledge bit
NAKNot acknowledge bit
PStop bit
In the “example” tables, later in this chapter , green-shaded table cells indicate the bits written by the slave.
Unshaded bits are written by the master. Gray-shaded entries are non-existent, for formatting purposes
only. Heavy borders around a table cell indicate those bits in the sequence that map to specific mailbox
locations.
All CI response packets utilize the same set of common return codes in the most-significant nibble of
Mailbox 1. Bit 8 is used as “Command Complete” or “COCO.” It is set to 0 when the command interpreter
first recognizes the incoming command, then is set to 1 when the command is complete (with or without
errors). COCO = 1 means that the command interpreter has done all it can with the command. Mailbox 1
bits 6-4 hold any applicable error code.
Table 7-4. Common CI error codes
Error name
PENDING0x0 - 0x70x0 - 0x7The command is still bein g executed.
RMF_ERROR_NONE0000x8Command completed with no errors
RMF_ERROR_PARAM0010x9
RMF_ERROR_PROT0100xA
RMF_ERROR_
SECURITY
RMF_ERROR_VERIFY1000xC
RMF_ERROR_RIGHTS1010xD
Error =
bits 6:4
01 10xB
Mailbox 1
MS nibble
Description
An input parameter did not pass muster. Examples include:
incorrect MEM field supplied in CI read/write packet and erase
password does not match RMF_ENABLE_FLASH_ERASE.
Returned when an attempt is made to program or erase flash while
flash protection is active (FOPT[PROTB] = 0). Call the CI function to
unprotect flash before attempting to program/erase the flash.
Most CI commands are unavailable when security has been set
(FOPT[SSC] = 10). This error code will be returned when an attempt
has been made to execute a prohibited function.
Returned as a result of a PROGRAM or ERASE command if the
final results of the operation do not match expected values. (ERASE
values are all Fs. PROGRAM values are the input values.)
The address offset of the first found error will be returned in
mailboxes 2 and 3. This error only occurs when the VERF bit is set
in the command byte.
Indicates that the user does not have access rights to perform a
function, such as attempting to write to ROM.
Generally applicable to cases where an input parameter is not within
an expected range of values. For example, a write command that
attempts to program flash memory across physical rows of the
device.
This code is returned when the command interpreter does not
recognize a command code or an incomplete packet is recognized.
ROM
7.5.4CI_DEV_INFO
This function returns the 32-bit device ID, along with ROM, flash and chip version numbers.
The Error Field of the Response Packet also returns a status code indicating whether or not the device is
secure.
7.5.4.1CI_DEV_INFO command-packet format
The five-bit command code for the device-info command is 0x00.The extension bits are 0.
Table 7-5. CI_DEV_INFO Command Packet Format at Mailbox Level
7.5.4.2CI_DEV_INFO response-packet format
The first byte of the response packet contains the command packet previously sent.
The second byte is a general status byte. COCO is set to 1 when the command response is complete. The
ERR field will be set to RMF_ERROR_SECURITY (0x3) if the device is in a secure state. This should be
treated as a status indicator, not an error , as other packet information will be correct, regardless of security
setting.
Additional mailboxes return:
•32-bit device ID
•ROM software version number (ROM_MAJOR.ROM_MINOR)
•Freescale flash-based software version number (FT_FLASH_MAJOR.FT_FLASH_MINOR)
•Hardware version number (HW_MAJOR.HW_MINOR)
Table 7-6. CI_DEF_INFO response packet format at mailbox level
This function encapsulates all memory read/write functions, including those required for programming
flash memory. Please note that flash memory must be erased prior to any program operation.
Memory mapped components, RAM, ROM and flash memory can be read/written with a common set of
memory-access sequences. Read commands require eight mailbox locations. W rite commands also require
eight locations, but with an additional payload of 0 to 24 bytes of write data stored in mailboxes 8 through
31.
Payload offsets map to on-chip addresses one-to-one. The first location accessed in the memory map
corresponds to the value specified with the MEM and ADDR[15:0] parameters. Addresses are
auto-incremented as the payload size increases.
NOTE
The 16-bit peripherals are restricted to word and long-word accesses on read
and write. Flash is restricted to long words during programming sequences.
The CI read/write commands are not responsible for checking that the
packet structure has data packet sizes which are Modulo 2 or 4 for the
various types. It is the responsibility of the user to make sure they are
correct.
Read response packets are two mailboxes plus the payload in length. Write respons e packets consume four
mailbox values.
7.5.5.2CI_READ_WRITE Read/Write memory command-packet format
The five-bit command code for the read/write command is 0x01.
Table 7-8. CI_READ_WRITE command-packet format at mailbox level
Table 7-9. CI_READ_WRITE command field descriptions
FieldDescription
Verify Writes (not applicable in Read accesses)
VERF
TYPE
MEM
NUMBER
0 Do not verify.
1 Verify that written value matches intent.
Type of Access
0 Write
1 Read
Memory Space
Values other than the following are reserved.
000 Flash memory
001 ROM (Valid CI_PW match required.)
010 RAM
011 RGPIO
100 8-bit peripherals
101 16-bit peripheral (Valid CI_PW match required.)
Number
Values other than the following are reserved.
Number of bytes to read/write.
0 NO-OP
1 to 28 for writes
1 to 30 for reads
CI_PW
ADDR
WDATA
Command Interpreter Password
Certain restricted functions require a Freescale-supplied password to unlock access.
The value of this parameter is ignored for non-restricted functions. “CI_READ_WRITE access/security policies”
on page 88 for details.
Address
The lower 16-bits of the first memory address to be accessed.
The upper bits are implied by the MEM variable.
Write Data
The NUMBER of bytes of data to be transferred in write command.
Flash program packets must contain payloads that are multiples of 4 bytes.
Table 7-12. CI_READ_WRITE command response field descriptions
Command Complete
Because flash program sequences take quite some time to complete, you may need to repeatedly poll the
port before the operation completes.
1 Previous command has been completed or aborted. (The ERR flag will be set for aborted sequences.)
0 Previous command not completed.
ERR
RDATA
VERF_ADDR
Error Flag
For the set of common CI error codes, see Table 7-4 on page 82.
Read Data
If ERR = 000, this is the NUMBER of bytes of data transferred in read command.
If ERR is any other value, the data contained in these bytes is not guaranteed.
Verify Address[15:0]
For write operations with verify, this is the lower 16 bits of the first location in which a verify error was
detected.
7.5.5.4CI_READ_WRITE access/security policies
Table 7-13 details security policies for the CI Read/Write command.
Table 7-13. Access/security policies for CI read/write memory command
Security enabledSecurity disabled
ReadWriteReadWrite
Main array of flash memoryNo accessAllowedSubject to PRR
RAMNo accessAllowed
ROMNo acces s
CI_PW match
required
Not allowed
16-bit peripheralsNo accessCI_PW match required
8-bit peripherals and RGPIONo accessAllowed
Policy descriptions are:
Subject to PRRWrites to flash memory are restricted to those in which the PRR
[page number] bit is 1b. Flash protection must be disabled prior
to any attempt at programming.
CI_PW match requiredA valid command interpreter password must be supplied.
7.5.5.5CI_READ_WRITE Read/Write memory example
This example does the following:
•Reads 4 bytes from RAM
•Starts at location 0x(00)80_0008
2
•Uses the I
88Freescal e Semiconductor, Inc.
C slave port, mapped to location 0x03 on the I2C bus
This function encapsulates all functions for page- and mass-erase actions of the flash memory.
The command packet is six mailboxes in length. The response packets are two to four mailboxes in length.
User requests for mass-erase will honor protection provided by the PRR. Only pages whose PRR bit is 1
will be erased. Effectively, the mass-erase operation is translated on the fly to a series of page-erase
operations.
Page-erase requests are not supported for secured devices. A mass-erase must be requested.
The same function call encapsulates both page- and mass-erase operations. The ROM software will use
mass-erase when possible, page-erase when not.
7.5.6.2Erase-command packet format
The five-bit command code for the erase command is 0x02.
Table 7-16. Command packet format at mailbox level
The main flash array on this device is composed of 32 512-byte pages of memory. A page is the minimum amount
of flash memory that can be erased in a single operation. The 32 bits of the mask variable correspond to pages 0
through 31. Page MASK[0] corresponds to the page starting at 0x(00)00_0000. MASK[31] corresponds to the page
starting at 0x(00)00_3E00. For each page, these bits have the following function:
MASK
1
“RMF_FLASH_PROTECT and RMF_FLASH_UNPROTECT” on page 111.
Erase operations are subject to usage rights previously established for the device. Some pages in flash memory
may be dedicated to Freescale-developed code. Erase requests for those pages will normally be rejected.
“Page-Release Register” on page 78 for additional details.
The Page Mask must be set to 0xFFFFFFFF for mass-erase requests. Other values will result in security violations
if the device is secured. It is necessary to unprotect flash memory
0 Do not erase.
1 Erase requested.
1
before attempting to erase it.
7.5.6.3Erase command response-packet format
The first byte of the response packet contains the command packet previously sent.
The second byte is a general status byte.
ROM
Table 7-18. CI_ERASE response packet format at mailbox level
This example performs a mass-erase of the upper portion of the main array in flash memory.
The command packet must write six mailbox registers in the slave port.
Table 7-21. Command to mass-erase flash on Device 4C on I2C bus
Start/Stop76543210
ROM
SSlave address = 0x4CR/W = 0
Register address = Mailbox 0 = 0x00A
Mailbox 0 = Mass erase main array only command = 0x12A
The response packet uses the I2C “combined format” that is described in “Message format for reading the
platform” on page 146. This format combines a write (to establish the slave address and first register
address) and a read of mailbox registers to transfer the required data. T able 8-10 shows the case where only
status information was retrieved. Diagnostic information in mailbox 2 and 3 was ignored.
Table 7-22. Response to previous mass-erase command on I2C bus
Start/Stop76543210
SSlave address = 0x04CR/W = 0
Register address= 0x00A
SSlave address = 0x4CR/W = 1
Mailbox 0 = Mass erase main array only command = 0x12A
Mailbox 1 = Status = 0x80 (command complete, no errors)NACK
CodeWarrior has the ability to calculate a CRC over a range of code and include it as part of the flash or
ROM image. This function replicates the same algorithm, which can be used to confirm code integrity over
time.
The CRC function will fail with a security violation if the device has security enabled.
7.5.7.1CI_CRC Checksum command-packet format
The 5-bit command code for the CRC command is 0x04. The command packet requires 8 mailboxes and
is shown in Table 7-23.
Table 7-23. Command packet format (RANGE=1, CS=1) at mailbox level
The Reset command configures FOP T[BF] to control flash/ROM Command Interpreter boot options and
initiates a reset by writing RCSR[SW] = 1. Because a hardware reset results from this operation, the
RESET command has no response packet unless an error is encountered. In cases of an error, the
“standard,” two-mailbox response packet is generated.
7.5.8.1CI_RESET command-packet format
The command packet requires two mailboxes.
The five-bit command code for the reset command is 0x05.
Table 7-30. CI_RESET Command-packet format at mailbox level
These complementary functions are used for toggling the state of the FOPT[PROTB] control bit. Flash
programing/erase checks the status of this bit prior to undertaking any changes to the flash array. If
FOPT[PROTB] = 0, the device is considered in a “protected” state and (except for BDM-initiated
mass-erase) the flash memory will not be modified. Any calls to CI_READ_WRITE or CI_ERASE to
modify the flash memory should be preceded by a call to CI_UNPROTECT and followed by a call to
CI_PROTECT.
7.5.9.1CI_PROTECT command-packet format
The five-bit command code for the CI_PROTECT command is 0x07 The extension bits are 0.
Table 7-37. CI_PROTECT Command Packet Format at Mailbox Level
7.5.9.3CI_PROTECT and CI_UNPROTECT response-packets format
The first byte of the response packet contains the command packet previously sent.
The second byte is a general status byte. COCO is set to 1 when the command response is complete.
7.5.9.4CI_PROTECT and CI_UNPROTECT access/security policies
Table 7-38 details security policies for the CI _PROTECT and CI_UNPROTECT commands.
Table 7-38. Access/Security Policies for CI Return Device Info Command
The primary function of the MMA955xL ROM is to provide a repository for flash programming/erase
firmware and perform some basic management of device functions. A small number of ROM functions
are accessible from user code. The calling hierarchy is illustrated in Figure 7-5.
All user-callable ROM functions are invoked via the call_trap() function. The C-prototype for this function
is:
Example 7-1. Invoking user-callable ROM functions
typedef union {
void * ptr;
unsigned long val;
} rmf_return_t;
rmf_return_t call_trap(unsigned short fid, void *ptr);
Input parameters are a function ID code (fid) and a void pointer which is internally recast to a structure
type specific to the function being called.
There are 32 bits of data returned. Depending on the function, these may be a pointer to a structure or
simply an unsigned long. When using the rmf_return_t C language data type, the user will need to specify
varName.ptr or varName.val, depending on the data type into which the user needs to cast the result.
It is possible to call ROM functions directly in assembler. An inspection of the call_trap() source code in
the example below shows how this is done. Simply load register D0 with the function ID and A0 with a
structure pointer . Then run the assembler “trap #0” instruction to transfer control to the supervisor routine
associated with that instruction.
The result will be returned in register A0.
Example 7-2. call_trap()
rmf_return_t call_trap(unsigned short fid, void *ptr)
{
rmf_return_t result;
asm {
move.w fid,d0 // D0 contains function ID (16 bits)
move.l ptr,a0 // A0 contains pointer to structure (32 bits)
trap #0
move.l a0,result // store in local 'result' variable
}
return result;
}
Only predefined, Freescale functions can be called via call_trap(). These are defined in Table 7-39.