CAN FLEXIBLE DATA (FD)

REBECA DELGADO / BERND ELEND

FIELD APPLICATIONS ENGINEER / PRINCIPAL ENGINEER
FTF-AUT-N1784
MAY, 2016

PUBLIC USE
 AGENDA
• CAN FD Protocol Overview
• FlexCAN3 FD
• MCAN FD
• Flexible Data and Partial Networking Impact on CAN
Physical Layer

1 PUBLIC USE #NXPFTF 1 PUBLIC USE #NXPFTF

 CAN FD

2 PUBLIC USE #NXPFTF

Increasing Bandwidth at Limited Cost
Flexible Data

Communication Bandwidth [ bit/s ]

• Increase bandwidth (x4, x8, x16)
• Low impact on Network Architecture & Cost
100M
• Minimal impact on Protocol and Physical Layer Ethernet,
MOST, USB,
1394-Firewire
10M Backbones, Diagnosis
FlexRay
Multimedia
5M time triggered
CAN FD TDMA
Fault Tolerant
1M Fault Tolerant,
CAN-HS 500kbps
By Wire Applications
CDMA Arbitration
Differential, Immune
125K
Global Standard
DSI – PSI5
Safety, Sensors

20K
LIN/J2602
time triggered
10K Master / Slave
Body, Powertrain
0.5 1 2.5 5
Relative Cost of Communication [ Cost/node ]
3 PUBLIC USE #NXPFTF
CAN FD
• CAN FD stands for CAN with Flexible Data-Rate
• CAN FD was a proposal by Bosch to
− Increase the baud rate of the data portion of a CAN message
− Increase the number of data bytes that can be sent in a single CAN message to up to 64
− No changes to arbitration field allow for existing physical layers to be used

4 PUBLIC USE #NXPFTF

Gradual transition
• Classical CAN nodes can’t listen to CAN FD frames.
• CAN FD nodes can send and receive Classical CAN frames.

• Are Classical CAN and CAN FD nodes able to coexist?

− Option1)
Introduction phase: CAN FD use only in specific operation modes
 E.g. software download at end of line programming with non CAN FD nodes in standby or sleep,
managed by CAN FD tolerant partial networking transceivers.

− Option2)
Use of CAN FD shield transceivers that make Classical CAN nodes deaf for CAN FD frames
(-> details will be disclosed in “FTF-AUT-N1775 Enabling Hybrid CAN Network: FD shield”)

5 PUBLIC USE #NXPFTF

Basic Concepts
• Bit rate
− Two bit rates in a CAN FD system,
ne for the arbitration phase and one for the data phase.

• Frame format:
− CAN BASE FRAME FORMAT (CBFF): 11 bit long identifier and constant bit rate
− CAN EXTENDED FRAME FORMAT (CEFF): 29 bit long identifier and constant bit rate
− CAN FD BASE FRAME FORMAT (FBFF): 11 bit long identifier and optional dual bit rate
− CAN FD EXTENDED FRAME FORMAT (FEFF): 29 bit long identifier and optional dual bit rate

6 PUBLIC USE #NXPFTF

Frame Format

Frame fields
START OF FRAME, ARBITRATION FIELD, CONTROL FIELD,
DATA FIELD, CRC FIELD, ACK FIELD, END OF FRAME

7 PUBLIC USE #NXPFTF

Frame Format
• The FD FRAME FORMAT (FDF) bit is recessive. It only exists in CAN FD format frames, it
distinguishes between CAN format and CAN FD format frames

F
D
F

8 PUBLIC USE #NXPFTF

Frame Format
• The BIT RATE SWITCH (BRS) bit decides whether the bit rate is switched inside a CAN FD format
frame. If recessive, the bit rate is switched immediately at the sample point of the BRS
Switching back to arbitration speed happens in this case at the sample point of the CRC delimiter.
Thus the BRS and the CRC delimiter are so called “mixed-bits”.

F
D
F

9 PUBLIC USE #NXPFTF

Frame Format
• The ERROR STATE INDICATOR (ESI) flag is transmitted dominant by error active nodes,
recessive by error passive nodes.

F
D
F

10 PUBLIC USE #NXPFTF

Data Payload
• CAN: # of
DLC3 DLC2 DLC1 DLC0
Data Bytes
−0 to 8 bytes 0 0 0 0 0

DLC in CAN Format and

1 0 0 0 1
• CAN FD

CAN FD Format
2 0 0 1 0
−0 to 64 bytes 3 0 0 1 1
4 0 1 0 0
5 0 1 0 1
6 0 1 1 0
7 0 1 1 1
CAN 8 1 x x x
format
8 1 0 0 0

DLC in CAN FD Format

12 1 0 0 1
16 1 0 1 0
20 1 0 1 1
24 1 1 0 0
32 1 1 0 1
48 1 1 1 0
64 1 1 1 1

11 PUBLIC USE #NXPFTF

Frame Format – CRC

• CAN: CRC_15 0xC599

(x15+x14+x10+x8+x7+x4+x3+1) = (x+1) · (x7+x3+1) · (x7+x3+x2+x+1)

• CAN FD < 16 bytes of data: CRC_17 0x3685B

(x17+x16+x14+x13+x11+x6+x4+x3+x1+1)
= (x+1) · (x16+x13+x10+x9+x8+x7+x6+x3+1)

• CAN FD > 16 bytes of data: CRC_21 0x302899

(x21+x20+x13+x11+x7+x4+x3+1)
= (x+1) · (x10+x3+1) · (x10+x3+x2+x1+1)

• All CRCs with Hamming Distance of HD = 6.

12 PUBLIC USE #NXPFTF

CAN FD CRC Issue
• When Bosch invented CAN, the CRC calculation did not consider bit stuffing.
• The initialization vector was chosen to be “0” (zero)

• Later it was recognized that the bit stuffing impacts the Hamming distance
• In Classical CAN : HD=2 and not HD=6

• With CAN FD Bosch included the stuff bits in the CRC calculation to overcome this problem
• However, in conjunction with the initialization vector of “0” (zero) it became worse!

13 PUBLIC USE #NXPFTF

CAN FD CRC Fixes
• Fix1:
• Change CRC initial value to use “1” followed by “0”s as the CRC polynomial seed
• Fix2:
• Add stuff bit 3-bit count , gray coded with additional parity bit at LSB, in front of CRC

4 added bits: 3-bit Modulo-8 stuff bit counter + 1 parity bit

calculated over the previous 3 bits

14 PUBLIC USE #NXPFTF

Implications of CAN FD Fixes
• There are now two versions of CAN FD

• non ISO CAN FD (original Bosch proposal)

• ISO CAN FD (ISO11898-1:2015) including the two fixes

15 PUBLIC USE #NXPFTF

CAN-FD Errata - CAN FD Errata Background
• Errata will be released shortly for a number of products that have the
“non ISO CAN FD” capabilities on them.
• These errata include:
− ERR008759 (for devices with FlexCAN3 (non ISO FD CRC ))
− ERR008860 (for devices with MCAN and a FSL wrapper (non ISO FD CRC ))
− ERR008923 (for devices with MCAN and a ST wrapper (non ISO FD CRC ))
• This errata was driven by this flaw in the CRC definition of the original CAN FD specification that
resulted in a need for a late change in the ISO 11898-1.

• This is not a bug in the controller silicon!

16 PUBLIC USE #NXPFTF

Other OEM Requirements
• Requirements
− Enhanced CRC that includes stuff bit count (ISO 11898-1:2015)
 GM, Ford, VW, Daimler AG, Renault, PSA have documented that they require full ISO
conformance
− Interleaving Classic CAN frames and CAN FD frames
 GM, Ford, VW have stated that they require ability to interleave classical and FD frame for series
productions.

17 PUBLIC USE #NXPFTF

Bit Rates
• Two bit rates:
− ARBITRATION-PHASE
 longer bit time = NOMINAL BIT RATE
− DATA PHASE
 same or shorter bit time <= NOMINAL BIT RATE

 Two bit rate register sets

18 PUBLIC USE #NXPFTF

Bit Time Segments
• Two prescalers  two TIME QUANTUM
− m(N) for the NOMINAL BIT TIME
− m(D) for the DATA BIT TIME
• The number of TIME QUANTA in a bit time shall be programmable at least from 8 to 25.

Bit Time NOMINAL BIT RATE DATA BIT RATE

Segment TIME QUANTA(N) TIME QUANTA(D)
SYNC_SEG 1 1
PROP_SEG 1, 2,…, 32 or more 0, 1, 2,…, 8
PHASE_SEG1 1, 2,…, 32 or more 0, 1, 2,…, 8
PHASE_SEG2 Max(PHASE_SEG1(N), IPT) Max(PHASE_SEG1(D), IPT)

19 PUBLIC USE #NXPFTF

CAN FD Bit Rate Example
• NOMINAL BIT TIME prescaler m(N) = 2

• DATA BIT TIME prescaler m(D) = 1

Keep both prescaler values

equal whenever possible!!

Make SJW in data phase

not bigger than mandated
by the precision of the clock
sources.

Make SJW in arbitration phase

big to allow for phase shifts at
loss of arbitration

20 PUBLIC USE #NXPFTF

 USING FLEXCAN3_FD

21 PUBLIC USE #NXPFTF

 FEATURES
• FlexCAN3-FD Module Features:
− Up to 128 Message buffers configurable as Tx or Rx
− Standard and Extended ID frames and Remote Frames* (not for FD)
− Payload: 0 to 64 bytes data length
− Programmable bit rate up to 8 Mb/sec
− Individual Rx Mask Registers per Message Buffer
− Full featured Rx FIFO
 Storage capacity for 6 frames and internal pointer handling with DMA
support
− Powerful Rx FIFO ID filtering
 Capable of matching incoming IDs against 128 extended, 256 standard or
512 partial (8 bits) IDs, with individual masking capability
 Programmable acceptance filters for receive message buffers
− 16-bit time Stamp, optional source
− Low Power operation via pretended networking feature

22 PUBLIC USE #NXPFTF 22 PUBLIC USE #NXPFTF

Protocol Bit Timing
• FlexCAN supports either oscillator or peripheral clock as CAN timing source

• Recall, FD frame requires two bit rates – Arbitration and data phase
• Bit timing parameters are achieved by setting up the following registers:
− Control register 1 (CTRL1): “Classical” CAN (equivalent FlexCAN2)
− CAN bit timing reg (CBT): Extended version of above register
− CAN FD bit timing reg (FDCBT): Bit time associated with FD data phase
• Bit time consists of following elements which are comprised from a variable number of time quanta
BIT TIME

SYNC_SEG PROP_SEG PHASE_SEG1 PHASE_SEG2

Transmit Point Sample Point

23 PUBLIC USE #NXPFTF
FlexCAN FD Bit Timing Examples

CAN_CTRL1 CAN_FDCBT

24 PUBLIC USE #NXPFTF

Transceiver Delay Compensation
• CAN transmitters are required to check for errors in their transmitted bits between their
CAN_Tx and CAN_Rx pins
− ISO11898 defines this delay at maximum of 255ns

• When higher bit rate data phase occurs in FD frame, the bit time that elapses until the
sample point can be shorter than the transceivers loop delay impeding correct comparison.

• A secondary sample point is defined where the transmitted bit is correctly compared with
the received bit to check for bit errors.

• Register to enable:
− CAN_FDCTRL[TDCEN]– enable, TDC only available once BRS is set (i.e. data phase)
− CAN_FDCTRL[TDCOFF] – offset value to assist in position of secondary sample point

25 PUBLIC USE #NXPFTF

 FlexCAN3 FD Message buffer structure
FD Bits

+8 bytes overhead

8-byte frame

16-byte frame

32-byte frame

64-byte frame
CAN 2.0
FD Enabled

26 PUBLIC USE #NXPFTF

 FlexCAN3 FD Memory Partitioning
• FlexCAN3 FD memory is partitioned in 4 blocks
• Essentially 128 x 8-byte payload buffers can be supported
80 • SoC can instantiate 1 to 4 blocks

Block 0 • Each block is composed by the memory space equivalent to 32 x 16-byte MBs or 512-
bytes (0x200)
280
• Each block can be configured to have message buffers (MBs) of a defined size in order to
store messages with payload of 8-byte, 16-byte, 32-byte or 64-bytes. Message buffer data
Block 1 size region bit field:
480 •FDCTRL[MBDSRn] = 0bxx

• The number of message buffers in a block depends upon payload size. Each block can be
configured (by software) as follows:
Block 2
680

Block 3
880

27 PUBLIC USE #NXPFTF

Transmit, Arbitrate, Move, Match and Receive!
Transmit
Process
• Scan MB for arbitration
winner
Arbitration Process • Scan IDs based on
priority if multiple nodes
transmit BUFFER 2 Move Out
BUFFER 1 (Tx)
Move Out Process • MB Winner
BUFFER 0 (Rx)

SERIAL BUFFERS
DATA Move

Transparent to user
• Rx MB are pre-programmed with

Rx Shifter
in

Tx Shifter
ID DATA LENGTH
Matching Process • Both FIFO and MBs can be
scanned
TIME STAMP
ID

Move in Process

Receive CANRx CANTx

Process CAN Bus

28 PUBLIC USE #NXPFTF

FlexCAN Rx FIFO
Rx FIFO cannot be used for CAN FD frames
Individual masks per MB
MailBox only Mode (RFEN bit =0)
FIFO and MailBox mode (RFEN bit =1)

MB0 MB1 MB2 MB3 MB4 MB5 MB6 MB7 MB8 MB126 MB127 MB128
6 Deep MB1
FIFO : MB1
MB1
MB1
MB0
Message Buffer Configuration
Filter Table Options:
Filter Table :
RXIDA: 128 x Standard or Extended IDs
8-128 entry filter table and masks
(includes IDE and RTR)
Filter on ID, IDE and RTR
RXIDB: 256 x Standard IDs or Extended
14-MSBit IDs slices (includes IDE and
Filter Mask Options: RTR)
Individual 32bit mask per table RXIDC: 512 x Standard or Extended 8-
. entry MSBit slices (includes IDE and RTR)
29 PUBLIC USE #NXPFTF
Rx FIFO Under DMA Operation
• Enhanced Feature
− DMA Request added to FlexCAN RxFIFO
 Allows CPU longer time to service the received CAN messages. With the DMA connected the depth of the FIFO should
also be able to be relatively small
 Enabled via the MCR[DMA]
 DMA Request asserted when any frame in FIFO
• DMA reads head of FIFO (0x80 to 0x8C). 8C must be read last to update for next FRAME

RxFIFO
System 5
RAM 4 RxFIFO
3 Control
2 Write_Pointer
System
DMA Read_Pointer
1
0 0x80 to 0x8C

DMA Req

DMA Ack

30 PUBLIC USE #NXPFTF

 USING MCAN FD

31 PUBLIC USE #NXPFTF

MCANs Features and user point
• Debug over M_CAN
• FD-Enabled
• 20kB shared message Random Access Memory (RAM)
• 128 Filter elements
• 2 configurable receive First In First Out registers (FIFO) for each module
• 64 dedicated receive and 32 dedicated transmit buffers
• 11 bit or 29 bit ID lengths

32 PUBLIC USE #NXPFTF

 MCAN FD Memory Partitioning

− The MCAN FD provides several data structures to store Messages, such as FIFOs and MBs
(Message Buffers). The data payload size for each data structure is fixed for a given module
configuration (configured by the software).

− For example: if the Rx FIFO 0 is defined to store 32-byte payload messages, it only
stores messages with size of up to 32-bytes payload.

Different sizes can be configured but

MCAN memory only 1 size for each data structure
partitioning
FIFOs and MBs data structures may
Rx FIFO 0 Rx FIFO 1 32 x Rx MB 32 x Tx MB store elements of one of the following
sizes (configured by the software) : 8,
12, 16, 20, 24, 32, 48 or 64

Since there is only one Tx structure,

only one message size is allowed.

CAN 2.0 and FD messages cannot be

interleaved. If FD mode is selected only
FD messages are treated.

Store Store Store Store

elements elements elements elements
of Size A of Size B of Size C of Size D

33 PUBLIC USE #NXPFTF

CAN Module Comparison
FlexCAN3_FD MCAN_3 TTCAN_2

Functional Differentiator Flexible Data Structure Shared RAM Shared RAM +

(mail box + FIFO) Message Time scheduling
FD Support Yes Yes Yes/Partial

MBs and FIFO Yes Yes Yes

Message RAM 2k RAM: Shared 20k RAM block*

Partitioned into
4 x 512 byte blocks**
ID Acceptance Filtering Yes Yes Yes

Debug over CAN No Yes Yes

DMA support Yes No No

Pretended Networking Yes No No

(low pwr support)
Optional ext timestamp with clock Yes No No

34 PUBLIC USE #NXPFTF

 AMP CAN FD
ROADMAP

35 PUBLIC USE #NXPFTF

 Hardware Security

Ethernet

AMP Product Offering and Roadmap USB

135-150C Ambient

S32V23xC CAN FD
ADAS 4x A53 1GHz, APEX, ISP, PCIe, SDHC, ASIL B, CAN-FD
Vision MPC560xE S32V23xG Vision processing for autonomous
Automated/Fusion
64MHz, 512K, M-JPEG 2x A53 600MHz, ASIL B, CAN-FD Surround cameras
S32V23xK
Surround SCP220x Short/Medium/Long range Radar
Front/rear
ARM926, APEX, MPEG-4
MPC577xK
Sensor Data Fusion
S32R27
2x 266MHz, Lockstep/ASILD, up to 4M, 2M, ASIL D, SPT2.0 S32R37
MPC567xK SPT1.0 - 3D FFT CAN-FD CAN-FD 1.2M, SPT2.5, ASIL B
Radar 2x 180MHz, up to 2M CAN-FD

MPC567xF/R
MPC5777C/M
VDS 1-2x 264Mhz, 4-6M
Multi-core up to 300MHz, Lockstep/ASIL D, 8M, HSM/CSE, CAN-FD (5777C)
MPC564xA Engine control
Powertrain/hybrid 150Mhz, 4M
MPC574xR Power steering
MPC563xM
80MHz, 1M
Multi-core 264MHz, Lockstep/ASIL D, 4M Braking
Chassis/safety
MPC5643L High-end Functional Safety and Security
2x 120MHz, lockstep/ASIL D, 1M MPC574xP
2x 200MHz, Lockstep/ASIL D, 2.5M
MPC560xP
64MHz, 512K

GATEWAY MPC574xG
Advanced FOTA MPC564xB/C Multi-core, 160MHz, ASIL B, 6M, HSM, MLB, ENET switch, CAN-FD Vehicle Gateway
Single-Dual-core, 120MHz, 3M, CSE
MPC574xB/C Body Controller
MPC5668G Single-Dual-core, 160MHz, ASILB, 3M, HSM, CAN-FD
Traditional ENET/FR Dual-core116MHz, 2M, MLB Audio Gateway
MAC57D5xx Multi Display Management and Clusters
MPC54xS
A5, M4, M0+, ASIL B Dual Display, SMD
Displays/Clusters 120MHz, 2M, VIU, SMD
MPC560xS
64MHz, up to 1M

GPIS MPC560xB S32K14x

32-bit 64Mhz, up to 1.5M M4F 112Mhz, up to 2M, CAN-FD, ASIL B
Body Electronic KEA General Purpose MCUs
M0+ 48Mhz up to 128K S12ZVMC
S12
16-bit 50Mhz, up to 1M S12ZVH
MCU w GDU +Vreg +PHY
S32K11x
Battery Management
Actuator/sensor MCU w LCD Driver, SMD, +Vreg +PHY S12ZC M0+ 48Mhz, up to 256K, CAN-FD, ASIL B BLDC Motor Control/ HVAC
FET/relay Motor S12ZVR MCU w CANPHY + Vreg, ASIL A High Voltage Integration
MCU w Low/High side driver + Vreg
CAN/LIN
S08 S12ZVL
LCD/Gauge 8-bit, up to 128K MCU w LINPHY + Vreg, ASIL A

1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q 1Q 2Q 3Q 4Q

2015 2016 2017

36 PUBLIC USE #NXPFTF Product Idea Concept Development Production
 FLEXIBLE DATA AND PARTIAL NETWORKING
IMPACT ON CAN PHYSICAL LAYER

37 PUBLIC USE #NXPFTF

ISO Standards Applicable to CAN Physical Layer
• CAN Flexible Data and Partial Networking
− Flexible data has been incorporated into the new ISO11898-1 XCVR
ECU_2

specification MCU
TxD
Trx

CAN bus
− ISO11898 -2, -5, and -6 will be merged into a new ISO11898-2 Protocol
Layer RxD Rec
specification ECU_n

− EMC/ESD target levels and limits may get tighter ECU_1

− Additional testing will be required for Partial Networking

− Requires better intrinsic Physical Layer performance and
functionality

Standards XCVR mode Operation

ISO11898-2 Transmit-Receive (Normal mode) Bi-directional interface to the physical bus

ISO11898-5 Low power mode and wake up Wake up on any CAN frame

Partial Networking, selective wake Wake up on a dedicated frame (ISO11898-1).

ISO11898-6
up (frame detect mode) Error management.

38 PUBLIC USE #NXPFTF

High Speed CAN Physical Layer
Simplified Architecture – ISO11898-2 and -5
Recessive Dominant
level level

Logic “1” Logic “0”

TxD
Vbat
CAN Bus
2.5V

Wake up Wake up
report receiver RxD
2.5V
+5V Bit representation
25k
sleep

Un powered
CAN H
Rxd
Differential
CAN receiver
2us/bit (500kb/s)
Protocol
(in MCU) Txd Pre
CAN L
TxD
driver 120//120

CAN
Bus

RxD

39 PUBLIC USE #NXPFTF

Signals at 500 kb/s, 2, 4 and 8 Mb/s
(ISO11898-2 Test Conditions: 60 ohms / 100 pF – “lab conditions” according to ISO11898-2)
2us/bit (500kb/s) 500ns/bit (2Mb/s)

TxD TxD

CAN CAN
Bus Bus

X4
RxD RxD

500kb/s 2Mb/s
X8
250ns/bit (4Mb/s) 125ns/bit (8Mb/s)

TxD TxD

CAN CAN
Bus Bus

RxD RxD

4Mb/s 8Mb/s
40 PUBLIC USE #NXPFTF
New Timing Definition

Ensure a minimum duration of the recessive level

More bit timing requirements are given in ISO11898-2 for 2Mbit/s and 5MBit/s

41 PUBLIC USE #NXPFTF

CAN Flexible Data Impact on ISO11898-6 Physical Layer

Idle phase detection (11 recessive bits)

SOF
ACK
SOF
Classical CAN Frame
FD frame detection(r0 bit) No idle phase detection during the Fast data
=> stop decoding

SOF
ACK
SOF
CAN FD Frame Fast data

Partial networking begin FD passive means:

• CAN Flexible Data frame shall not “disturb” Partial Networking transceiver:
• The circuitry must be designed to avoid “Error Detection” and to prevent the
Frame Error Counter from increasing and falsely waking up the transceiver
• Proper detection of “End of frame / Idle detection”

42 PUBLIC USE #NXPFTF

Conclusion
• Industry trend is increased bandwidth and EMC robustness combined with
energy savings
• CAN Network is evolving with emergence of CAN Partial Networking and CAN
Flexible Data standards to support these needs, alone or combined together
• At Physical Layer there are conflicting challenges:
− Improving bandwidth, reduce immunity to power injection and increase noise emission
level
− Reducing quiescent current, improving noise immunity, EMC, and ESD continue to be
extremely important.
− Need to sustain performance without need for common mode choke
• NXP is focusing analog innovations to support High Speed CAN, CAN FD and
Partial Networking

43 PUBLIC USE #NXPFTF

ATTRIBUTION STATEMENT
NXP, the NXP logo, NXP SECURE CONNECTIONS FOR A SMARTER WORLD, CoolFlux, EMBRACE, GREENCHIP, HITAG, I2C BUS, ICODE, JCOP, LIFE VIBES, MIFARE, MIFARE Classic, MIFARE
DESFire, MIFARE Plus, MIFARE FleX, MANTIS, MIFARE ULTRALIGHT, MIFARE4MOBILE, MIGLO, NTAG, ROADLINK, SMARTLX, SMARTMX, STARPLUG, TOPFET, TrenchMOS, UCODE, Freescale,
the Freescale logo, AltiVec, C 5, CodeTEST, CodeWarrior, ColdFire, ColdFire+, C Ware, the Energy Efficient Solutions logo, Kinetis, Layerscape, MagniV, mobileGT, PEG, PowerQUICC, Processor Expert,
QorIQ, QorIQ Qonverge, Ready Play, SafeAssure, the SafeAssure logo, StarCore, Symphony, VortiQa, Vybrid, Airfast, BeeKit, BeeStack, CoreNet, Flexis, MXC, Platform in a Package, QUICC Engine,
SMARTMOS, Tower, TurboLink, and UMEMS are trademarks of NXP B.V. All other product or service names are the property of their respective owners. ARM, AMBA, ARM Powered, Artisan, Cortex,
Jazelle, Keil, SecurCore, Thumb, TrustZone, and μVision are registered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. ARM7, ARM9, ARM11, big.LITTLE, CoreLink,
CoreSight, DesignStart, Mali, mbed, NEON, POP, Sensinode, Socrates, ULINK and Versatile are trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. Oracle and
Java are registered trademarks of Oracle and/or its affiliates. The Power Architecture and Power.org word marks and the Power and Power.org logos and related marks are trademarks and service marks
licensed by Power.org. © 2015–2016 NXP B.V.

45 PUBLIC USE #NXPFTF