FlexRay Module Training

11/9/2015

TI Safety Microcontroller

FlexRay Summary

FlexRay Overview 3

TI’s FlexRay Implementation 27

FlexRay Transfer Unit (FTU) 45

FlexRay Interrupt Structure 59

2 11/9/2015

FlexRay Overview

Future Needs for Networking

4 11/9/2015

Future applications have additional requirements to a bus system

• dependability

• determinism

• robustness

• fault-tolerant

FlexRay Key Features

• Open Bus System

• Support of redundant transmission channels

• Data rate of 10 Mbit/sec per channel

• Support of a fault tolerant synchronized global time base

• Static and dynamic data transmission (scalable)

Deterministic data transmission

Arbitration free transmission

• Fault tolerant and time triggered services implemented in hardware

• Support of optical and electrical physical layers

5 11/9/2015

FlexRay Protocol HardWare

6 11/9/2015

Demo: There are 13 nodes in our network. 1 is TMS570LS3137, and others

are TMS570LS20216

FlexRay Architecture -- ECU

7 11/9/2015

• Flexray Node: ECU

FlexRay Architecture –Protocol Operation Control

8 11/9/2015

FlexRay controller states: 1 – default config

2 – config

3 – ready

4 – wakeup

5 – startup

6 – normal active

7 – normal passive

8 – halt

FlexRay Architecture – Network Topology

9 11/9/2015

FlexRay Architecture – Network Topology

10 11/9/2015

FlexRay Architecture – Network Topology

11 11/9/2015

• Intended to eliminate single-point failures for critical systems

• This seems the most likely configuration for FlexRay X-by-Wire

• TTP was found to have some distributed bus guardian issues

• Problems related to nodes listening to faulty network startup messages

• Latest proposal is to move to dual channel star configuration for TTP as well

FlexRay – Signal on FR BUS

12 11/9/2015

• Differential NRZ encoding

• 10 Mbps operating speed

• Independent of network length because, unlike CAN, doesn’t use bit arbitration

FlexRay Protocol -- Frame Format

13 11/9/2015

•• This data is encoded into NRZ bytes per the encoding format

FlexRay Protocol -- Frame Encoding

14 11/9/2015

FlexRay Protocol -- Coding

15 11/9/2015

• Data sent as NRZ bytes

• TSS = Transmit Start Sequence (LOW for 5-15 bits)

• FSS = Frame Start Sequence (one HI bit)

• BSS = Byte Start Sequence (similar to start/stop bits in other NRZ)

• FES = Frame End Sequence (END symbol for frame – LO + HI)

• Dynamic segment frames are similar

• Adds a DTS = dynamic trailing sequence field; helps line up minislots

Cycle [n] Cycle [n+1] Cycle […]

FlexRay Communication Structure

16 11/9/2015

static

segment

dynamic

segment

symbol

window NIT

static

segment

dynamic

segment static

segment

dynamic

segment

symbol

window NIT

payload hea

der trailer CID payload

hea

der trailer CID

the payload length can vary

slot 1 slot 2 slot 3 … slot

m-1 slot m

m

+

1

m

+

2

m

+

3

dynamic

slot m+4

m

+

5

m

+

6

dynamic

slot 7

.

.

.

m

+

x

FlexRay Communication Cycle

17 11/9/2015

Static Segment Dynamic Segment

FlexRay Message Cycle

18 11/9/2015

• Two main phases: static & dynamic

• “Temporal firewall” – partition between phases protects timing of each phase

Microtick & Macrotick

19 11/9/2015

• Microtick level

• Node’s own internal time base

• Direct or scaled value from a local oscillator or counter/timer

• Not synchronized with rest of system – local free-running oscillator

• Macrotick level

• Time interval derived from cluster-wide clock sync algorithm

• Always an integral number of microticks

• BUT, not necessarily the same number of microticks per node

• Number of microticks varies at run time to implement clock sync

• Designated macrotick boundaries are “action points”

• Transmissions start here – static; dynamic; symbol window

• Transmissions end here – dynamic segment

Static Segment

20 11/9/2015

TDMA messages, most likely used for critical messages

• All static slots are the same length in microticks

• All static slots are repeated in order every communication cycle

• All static slot times are expended in cycle whether used or not

• Number of static slots is configurable for system ; up to 1023 slots

Static Segment Details

21 11/9/2015

Two-channel operation

• Sync frames on both channels; other frames optionally 1 or 2 channels

• Less critical/less expensive nodes might only connect to one channel

• Slots are lock-stepped in order on both channels

TDMA order is by ascending frame ID number

• Frame number used to determine slot # by software

1. It is NOT a binary countdown arbitration mechanism – only one xmitter at a time

2. Optionally, there is a Message ID in the payload area that can be unrelated to slot

number

3. Example use: each node uses its node # as frame # and multiplexes its messages

onto a single time slot, distinguished by Message ID

• In contrast, TTP has a MEDL that can have sub-cycles

1. Need neither a Frame ID nor a Message ID

2. Extra information to be managed and coordinated

Dynamic Segment

22 11/9/2015

High-level idea is event-based communication channel

• Want arbitration, but must be deterministic

• Binary countdown not used (among other things, restricts possible media)

“Minislot” approach

• Can be thought of as a time-compressed TDMA approach (details on next slide)

• Two channels can use independent message queues

Dynamic Segment Details

23 11/9/2015

High-level idea is each minislot is an opportunity to send a message

• If message is sent, minislot expands into a message transmission

• If message isn’t sent, minislot elapses unused as a short idle period

• All transmitters watch whether a message is sent so they can count minislots

Minislot Performance

24 11/9/2015

Frame ID # is used for slot numbering

• First dynamic Frame ID = last static Frame ID + 1

Dynamic segment has a fixed amount of time

• Fixed number of macroticks, divided up into minislots

• There might or might not be enough time for all dynamic messages to be sent

• When dynamic segment time is up, unsent messages wait for next cycle

Net effect: event-triggered messages

• Messages with the lowest Frame ID are sent first

• Each Frame ID # can only send ONE message per cycle

• As many message as will fit in dynamic segment are sent

• This means that only highest priority messages queued are sent in each cycle

• Note that idle minislots consume dynamic segment bandwidth

• But minislots are a lot smaller than messages

System Startup of FlexRay

25 11/9/2015

First, a wakeup procedure

• Transition controllers from “sleep” to “wake”

• (Not necessarily initiated by a coldstart node)

Then, a coldstart, that actually starts the TDMA operation

• At least two coldstart nodes in system

• For systems with 3 or more nodes, ideal number is three coldstart

nodes

More than 3 nodes might have problems with forming a single

group (clique avoidance on startup works only for 3 nodes)

• Coldstart nodes are pre-designated in system

Wakeup Pattern

26 11/9/2015

Wakeup pattern sent on one channel to alert other nodes to wake up

• Pattern sent multiple times in general – example shows sending it twice

• Only sent on one channel at a time

Have to handle case where sending wakeup is a single-point fault

• Wakeup isn’t acknowledged by nodes

That is dealt with during startup

TI’s FlexRay Implementation

Key Features (1/2)

28 11/9/2015

• FlexRay Core (E-Ray)

• Conform to FlexRay Protocol Specification V2.1 RevA

• Data rates of up to 10 Mbit/s on each of the 2 channels

• 8 Kbyte of Message RAM for storage of e.g. 128 message buffers with max. 48 byte data section or

30 message buffers with 254 byte data section

Different payload lengths possible

• Parity Protection of Message RAM

• Message Handler controls

Message RAM access arbitration

Acceptance Filtering

Maintaining the transmission schedule

Providing status information

Key Features (2/2)

29 11/9/2015

• Each message buffer can be configured as Receive buffer

Transmit buffer

• Each message buffer can be assigned to Static segment of the Communication Cycle

Dynamic segment of the Communication Cycle

Part of a receive FIFO

• 2 Module Interfaces Direct CPU access to message buffers via input and output buffer

Transfer Unit for automatic data transfer between data memory and message

buffers without CPU interaction

• Filtering for frame ID, channel ID and cycle counter

• Maskable module interrupts

• Network Management supported

Block Diagram

30 11/9/2015

FTU: FlexRay Transfer Unit

IBF: Input Buffer (relative to msg handler)

OBF: Output Buffer

INT: Interrupt Control

TBF A/B: Transient Buffer RAM

PRT A/B: FlexRay Channel Protocol Controller

GTU:

Global Time Unit

SUC: System Universal Control

FSP:

Frame and Symbol Processing

NEM: Network Management

Message Buffers in the Message RAM

31 11/9/2015

Note: The Message RAM of the Communication Controller is not memory mapped

The message RAM has a structure as shown in

right diagram

The data partition is allowed to start at Message

RAM word number: (MRC.LCB + 1) • 4

Header Partition: Stores header segments of

FlexRay frames. Each message buffer has a

header of four 32 bit words.

Data Partition: Flexible storage of data sections

with different length.

Restriction: header partition + data partition may

not occupy more than 2048 x 32 bit words.

Module Block Memory Map

32 11/9/2015

Note: The Message RAM of the Communication Controller is not memory mapped

CPU Access to Message RAM

33 11/9/2015

• The data transfer between CPU and Message

Buffer is done via a Input- and Output Buffer

register set

• Each, Input- and Output Buffer register set, can

hold one message frame (Header + Payload)

• Input Buffer (IBF) and Output Buffer (OBF) are

build up as a double buffer structure

• The message transfer is triggered by the CPU

CPU

Data Organization in Interface Registers

34 11/9/2015

Input Buffer (IBF)

Write Header Section 1 (WRHS1)

Write Data Section 1 (WRDS1)

31 0

Head

er

Paylo

ad

Input Buffer Command Mask (IBCM)

Input Buffer Command Request (IBCR)

Write Data Section 2 (WRDS2)

Write Data Section 64 (WRDS64)

Write Header Section 2 (WRHS2)

Write Header Section 3 (WRHS3)

addr

offset

0x500

0x400

Output Buffer (OBF)

Read Header Section 1 (RDHS1)

Read Data Section 1 (RDDS1)

31 0

Head

er

Paylo

ad

Output Buffer Command Mask (OBCM)

Output Buffer Command Request (OBCR)

Read Data Section 2 (RDDS2)

Read Data Section 64 (RDDS64)

Read Header Section 2 (RDHS2)

Read Header Section 3 (RDHS3)

Message Buffer Status (MBS)

addr

offset

0x700

0x600

Data Transfer from Input Buffer to Message RAM 1/3

35 11/9/2015

• When the Host writes the number of the target message buffer in the Message RAM to Input

Buffer Command Register, IBF Host and IBF Shadow are swapped

• While the Message Handler transfers the data from IBF Shadow to the target message

buffer in the Message RAM, the CPU may write the next message to IBF Host.

CPU

Message

Handler

Co

ntr

ol

Data Transfer from Input Buffer to Message RAM 2/3

36 11/9/2015

Data Transfer from Input Buffer to Message RAM 3/3

37 11/9/2015

• Example of a 8/16/32-bit host access sequence:

1. Configure / update n-th message buffer through IBF

2. Wait until IBCR.IBSYH is reset

3. Write data section to WRDSn

4. Write header section to WRHS1,2,3

5. Write command mask: write IBCM.STXRH, IBCM.LHSH, IBCM.LDSH

6. Demand data transfer to target message buffer: write IBCR.IBRH(6-0)

• Configure / update further message buffer through IBF in the same

Data Transfer from Message RAM to Output Buffer 1/3

38 11/9/2015

• For reading a message buffer from the Message RAM, the CPU has to write to the Output

Buffer Command Register to trigger the data transfer from the target message buffer to the

OBF Shadow

• After the transfer between the Message RAM and OBF Shadow has completed, the CPU

has to set a VIEW bit to swap OBF Shadow and OBF Host

• While the CPU reads the transferred message buffer from OBF Host, the Message Handler

may transfer the next message from the Message RAM to OBF Shadow.

CPU

Message

Handler

Co

ntr

ol

Data Transfer from Message RAM to Output Buffer 2/3

39 11/9/2015

• Writing bit OBCR.REQ in the output buffer command request register to 1 copies bits

OBCM.RHSS, OBCM.RDSS from the output buffer command mask register and bits

OBCR.OBRS(6-0) from the output buffer command request register to an internal storage

Data Transfer from Message RAM to Output Buffer 3/3

40 11/9/2015

Example of host access to a single message buffer:

If a single message buffer has to be read out, two separate write accesses to OBCR.REQ

and OBCR.VIEW are necessary:

• Wait until OBCR.OBSYS is reset

• Write Output Buffer Command Mask OBCM.RHSS, OBCM.RDSS

• Request transfer of message buffer to OBF Shadow by writing OBCR.OBRS(6-0) and

OBCR.REQ (in case of and 8-bit Host interface, OBCR.OBRS(6-0) has to be written

before OBCR.REQ).

• Wait until OBCR.OBSYS is reset

• Toggle OBF Shadow and OBF Host by writing OBCR.VIEW = 1

• Read out transferred message buffer by reading RDDSn, RDHS1,2,3, and MBS

FlexRay Protocol Controller Access to Message RAM

41 11/9/2015

The FlexRay module contains the

following RAM portions:

1. Message RAM

2. Transient Buffer RAM Channel A

(TBF A)

3. Transient Buffer RAM Channel B

(TBF B)

4. Input Buffer (IBF)

5. Input Buffer Shadow (IBFS)

6. Output Buffer (OBF)

7. Output Buffer Shadow (OBFS)

8. Transfer Configuration RAM (TCR)

All RAMs except the TCR are part of

the Communication Controller core.

Message RAM Configuration

42 11/9/2015

Header: FDB: First Dynamic Buffer

FFB: First Buffer of FIFO

LCB: Last Configured Buffer

Data: The data section of a message buffer is referenced by the data pointer configured in the header section.

Each FlexRay Buffer consists of a Header and a Data section

Header Partition

43 11/9/2015

Data (Payload) Partition

44 11/9/2015

• The data partition starts after the last word of the header partition

• The beginning and the end of a message buffer’s data section is determined by the

data pointer and the payload length configured in the message buffer’s header section

• The programmer has to assure that the data pointers point to addresses within the

data partition

Filtering and Masking of FlexRay Frames

45 11/9/2015

The following filter combinations for acceptance / transmit filtering are

allowed:

• Slot Counter + Channel ID

• Slot Counter + Cycle counter + Channel ID

Receive Filtering:

In order to store a received message in a message buffer all configured

filters must match.

Transmit Filtering:

A message will be transmitted in the time slot corresponding to the

configured frame ID on the configured channel(s).

If cycle counter filtering is enabled the configured cycle filter value must

also match.

FlexRay Transfer Unit (FTU)

FTU Data Transfer Scheme

47 11/9/2015

FlexRay Transfer Unit Key Features (1/2)

48 11/9/2015

• Data Transfer without CPU interaction

From FlexRay Message RAM to Data RAM (Read)

From Data RAM to FlexRay Message RAM (Write)

• Transfer Types

data and header section

header section only

data section only

• Transfer Configuration RAM (with Parity) Configures the transfer sequence

Parity protection

• Triggers to Start a Transfer CPU driven (single transfer sequence)

Event driven (single or continuous transfer sequence)

FlexRay Transfer Unit Key Features (2/2)

49 11/9/2015

• Different Transfer Conditions If the status flags (header section) of the respective message

buffer has been updated

If the data section of the respective message buffer has been

updated

Always

• Maskable interrupt generation when Message Buffer

transfer is finished

• Memory Protection Unit

One memory section (start- and end address) can be

defined

No memory section is setup after reset

FlexRay Transfer Unit (FTU) Sub Blocks

50 11/9/2015

FlexRay Transfer Unit

1

2

3

128

TCR

MTD[3:0]

Register

TCR = Transfer Configuration RAM

TSA = Transfer Start Addresses (RAM)

MTD = Message Transfer Direction Register

TBR = Transfer Buffer to RAM Register

TRB = Transfer RAM to Buffer Register

TC = Transfer Control Register

LTB = Latest Transferred Buffer

MTRIM[3:0] = Message Transfer Ready Interrupt Mask Register

MTILS[3:0] = Message Transfer Interrupt Level Select Register

MTIF[3:0] = Message Transfer Interrupt Flag Register

EIM = Error Interrupt Mask Register

EILS = Error Interrupt Level Select Register

EIF = Error Interrupt Flag Register

Finite State

Machine (FSM)

Interrupt

Memory Protection

TBR

TRB

TC

LTB

MTRIM[3:0]

MTILS[3:0]

MTIF[3:0]

EIM

EILS

EIF

FlexRay Core VBUS

Transfer Configuration RAM (TCR)

51 11/9/2015

Each Entry defines:

• Transfer Address offset

• Transfer direction

• Transfer of Header and/or Payload

• Automatic send trigger to FlexRay

core

18 0

Entry 1

Entry 2

Entry 3

Entry 4

Entry 128

Executio

n fro

m lo

wer to

hig

her E

ntry

• Used to setup a transfer sequence

• Entry number is equal to the message buffer number of the

FlexRay

• A transfer cycle is executed from lower to higher entry number

• The Transfer Configuration RAM is parity protected.

FTU Data Addressing

52 11/9/2015

Data Package Storage Order in Data RAM

53 11/9/2015

• Header segments are always 4

words.

• Payload Length is configured in the

FlexRay core

• The data transferred by the TU can

be selected as:

data and header section

header section only

data section only

• The Buffer Status is transferred

only from Communication

Controller to System Memory

Header 1

Header 2

Header 3

Payload 1

31 0

always 4 words

depends on the

payload length

configured in the

FlexRay core

Payload 2

Payload 64

Buffer Status

Possible Transfer Sequence Modes

• Manually by setting the according bit in the Trigger Transfer to System Memory Register

(TTSM) or the Trigger Transfer to Communication Controller Register (TTCC)

• Event-Driven using the Enable Transfer on Event to System Memory Register (ETESM)

– Only transfers from FlexRay Communication Controller to the System

Memory

– Transfer trigger occurs upon completion of reception or transmission of a

frame via the FlexRay bus

• Continuously

by using the Clear on Event to System Memory (CESM)

54 11/9/2015

Transfer Status Indication

There are 3 registers indicating the transfer status

• Transfer Status Current Buffer (TSCB) shows the current transfer buffer status

• Last Transferred Buffer to Communication Controller (LTBCC) shows the last completed buffer transfer to the communication controller

• Last Transferred Buffer to System Memory (LTBSM) shows the last completed buffer transfer to system memory

55 11/9/2015

Transfer Priority

• The TU will transfer the message buffers from low to high message

buffer numbers.

• In case the same buffer is pending in both

the Trigger Transfer to Communication Register (TTCC)

the Trigger Transfer to System Memory Register (TTSM)

the priority between TTCC and TTSM is determined by the Transfer Priority

bit (GC.PRIO) in the TU Global Control Register.

57 11/9/2015

Memory Protection Mechanism • One memory section can be defined in the data RAM, which allows

read and write accesses for the Transfer Unit State Machine.

• In case of a protection violation

the transfer will not be performed

a flag will be set

the Memory Protection Violation interrupt will be activated

The Transfer Unit State Machine will be disabled

• Default the setting of the protection address range: • 0x00000000 for startaddress

• 0x00000000 for endaddress

a valid address range must be setup, before the Transfer Unit can be used.

59 11/9/2015

FlexRay Interrupt Structure

FlexRay Core Interrupt Structure

61 11/9/2015

• Error and Status interrupts can

be generated

• Each interrupt source can be

mapped to one of the 2 interrupt

lines

• Timer0 and Timer1 interrupt

have private interrupt lines

• Interrupt flag for each interrupt

source

FTU Interrupt Structure

62 11/9/2015

• Each transfer channel can

generate a transfer interrupt

• Parity and Memory Protection

error have private interrupt lines

• Further error interrupts can be:

Read transfer error

Write transfer error

Transfer not ready

Forbidden access of CPU to IBF or OBF

• Interrupt flag for each interrupt source

SPRT718

IMPORTANT NOTICE

Texas Instruments Incorporated and its subsidiaries (TI) reserve the right to make corrections, enhancements, improvements and otherchanges to its semiconductor products and services per JESD46, latest issue, and to discontinue any product or service per JESD48, latestissue. Buyers should obtain the latest relevant information before placing orders and should verify that such information is current andcomplete. All semiconductor products (also referred to herein as “components”) are sold subject to TI’s terms and conditions of salesupplied at the time of order acknowledgment.TI warrants performance of its components to the specifications applicable at the time of sale, in accordance with the warranty in TI’s termsand conditions of sale of semiconductor products. Testing and other quality control techniques are used to the extent TI deems necessaryto support this warranty. Except where mandated by applicable law, testing of all parameters of each component is not necessarilyperformed.TI assumes no liability for applications assistance or the design of Buyers’ products. Buyers are responsible for their products andapplications using TI components. To minimize the risks associated with Buyers’ products and applications, Buyers should provideadequate design and operating safeguards.TI does not warrant or represent that any license, either express or implied, is granted under any patent right, copyright, mask work right, orother intellectual property right relating to any combination, machine, or process in which TI components or services are used. Informationpublished by TI regarding third-party products or services does not constitute a license to use such products or services or a warranty orendorsement thereof. Use of such information may require a license from a third party under the patents or other intellectual property of thethird party, or a license from TI under the patents or other intellectual property of TI.Reproduction of significant portions of TI information in TI data books or data sheets is permissible only if reproduction is without alterationand is accompanied by all associated warranties, conditions, limitations, and notices. TI is not responsible or liable for such altereddocumentation. Information of third parties may be subject to additional restrictions.Resale of TI components or services with statements different from or beyond the parameters stated by TI for that component or servicevoids all express and any implied warranties for the associated TI component or service and is an unfair and deceptive business practice.TI is not responsible or liable for any such statements.Buyer acknowledges and agrees that it is solely responsible for compliance with all legal, regulatory and safety-related requirementsconcerning its products, and any use of TI components in its applications, notwithstanding any applications-related information or supportthat may be provided by TI. Buyer represents and agrees that it has all the necessary expertise to create and implement safeguards whichanticipate dangerous consequences of failures, monitor failures and their consequences, lessen the likelihood of failures that might causeharm and take appropriate remedial actions. Buyer will fully indemnify TI and its representatives against any damages arising out of the useof any TI components in safety-critical applications.In some cases, TI components may be promoted specifically to facilitate safety-related applications. With such components, TI’s goal is tohelp enable customers to design and create their own end-product solutions that meet applicable functional safety standards andrequirements. Nonetheless, such components are subject to these terms.No TI components are authorized for use in FDA Class III (or similar life-critical medical equipment) unless authorized officers of the partieshave executed a special agreement specifically governing such use.Only those TI components which TI has specifically designated as military grade or “enhanced plastic” are designed and intended for use inmilitary/aerospace applications or environments. Buyer acknowledges and agrees that any military or aerospace use of TI componentswhich have not been so designated is solely at the Buyer's risk, and that Buyer is solely responsible for compliance with all legal andregulatory requirements in connection with such use.TI has specifically designated certain components as meeting ISO/TS16949 requirements, mainly for automotive use. In any case of use ofnon-designated products, TI will not be responsible for any failure to meet ISO/TS16949.

Products ApplicationsAudio www.ti.com/audio Automotive and Transportation www.ti.com/automotiveAmplifiers amplifier.ti.com Communications and Telecom www.ti.com/communicationsData Converters dataconverter.ti.com Computers and Peripherals www.ti.com/computersDLP® Products www.dlp.com Consumer Electronics www.ti.com/consumer-appsDSP dsp.ti.com Energy and Lighting www.ti.com/energyClocks and Timers www.ti.com/clocks Industrial www.ti.com/industrialInterface interface.ti.com Medical www.ti.com/medicalLogic logic.ti.com Security www.ti.com/securityPower Mgmt power.ti.com Space, Avionics and Defense www.ti.com/space-avionics-defenseMicrocontrollers microcontroller.ti.com Video and Imaging www.ti.com/videoRFID www.ti-rfid.comOMAP Applications Processors www.ti.com/omap TI E2E Community e2e.ti.comWireless Connectivity www.ti.com/wirelessconnectivity

Mailing Address: Texas Instruments, Post Office Box 655303, Dallas, Texas 75265Copyright © 2015, Texas Instruments Incorporated