Cypress AN224283 User Manual
Please note that Cypress is an Infineon Technologies Company.
The document following this cover page is marked as “Cypress” document as this is the
company that originally developed the product. Please note that Infineon will continue
to oer the product to new and existing customers as part of the Infineon product
portfolio.
Continuity of document content
The fact that Infineon oers the following product as part of the Infineon product
portfolio does not lead to any changes to this document. Future revisions will occur
when appropriate, and any changes will be set out on the document history page.
Continuity of ordering part numbers
Infineon continues to support existing part numbers. Please continue to use the
ordering part numbers listed in the datasheet for ordering.
www.infineon.com
www.cypress.com Document Number: 002-24283 Rev. *B 1
AN224283
How to Use CXPI Controller in Traveo II Family
Author: Quang Pham Minh
Associated Part Family: Traveo™ II Family CYT2/CYT3/CYT4 Series
Related Documents: see Related Documents
This application note describes how to use the Clock Extension Peripheral Interface (CXPI) controller in Traveo™ II
family MCU. The CXPI Controller of Traveo II supports autonomous transfer of the CXPI frame, to reduce the CPU
processing.
Contents
1 Introduction .................................................................. 1
2 Overview of CXPI ........................................................ 1
2.1 CXPI Network ..................................................... 1
2.2 CXPI Bus Access Method ................................... 2
2.3 Message Frame Format ...................................... 3
3 CXPI Controller in Traveo II ......................................... 4
3.1 Mode of Operation .............................................. 4
3.2 Baud Rate and Sampling Concept ...................... 5
3.3 CXPI Message Transmission Commands and
Interrupt Events ................................................... 6
3.4 PID Arbitration .................................................... 9
4 Example of CXPI Controller Operation ...................... 10
4.1 CXPI Controller Initialization ............................. 11
4.2 Message Frame Transmission/Reception ......... 13
5 Glossary .................................................................... 26
6 Related Documents ................................................... 26
Document History ............................................................ 27
Worldwide Sales and Design Support ............................. 28
1 Introduction
This application note describes how to use the CXPI controller in Traveo™ II family MCU.
To understand the described functionality and the terminologies used in this application note, see the “Clock Extension
Peripheral Interface (CXPI)” chapter of the Architecture Technical Reference Manual (TRM).
This document is applicable to CYT2/CYT3/CYT4 Series devices.
2 Overview of CXPI
This section provides an overview of CXPI communication.
2.1 CXPI Network
Figure 1 shows an example of the CXPI network in a vehicle.
CXPI protocol provides a low speed, low cost, and light weight connection in automotive controls of simple devices like
wipers, sensors, or switches. As an example, in Figure 1, the MCU with a CXPI controller would be the CXPI master
node whereas, the devices attached to the CXPI network would be the CXPI slave nodes. The CXPI controller can
control the devices, get status and confirmation from devices via the CXPI communication bus.
Comparing to LIN protocol, CXPI protocol provides a better performance in communication since it can handle
multiplexing between multiple devices in a more efficient manner by making the arbitration decision at the lower layer
(hardware) rather than having higher layer (software) assistance. Table 1 shows an overview of CXPI protocol feature.
How to Use CXPI Controller in Traveo II Family
www.cypress.com Document Number: 002-24283 Rev. *B 2
Figure 1. Example of CXPI Network in a Vehicle
MCU with
CXPI
Controller
Interface
CXPI bus
Light
Light
Light
Light
Wiper
Wiper
Steering
Light
Light
Table 1. CXPI Protocol Feature
Terms
Description
Network layout
• Single master node and multiple slave nodes
• Data with clock is transmitted and received on a single communication bus
• Up to 16 nodes connected to a CXPI communication bus
Communication baud rate
Maximum baud rate of 20 kbit/s.
Network protocol
Collision Resolution supported Carrier Sense Multiple Access (CSMA/CR)
Bus access method
• Event Trigger method to support the responsiveness of slave node
communication
• Polling method to support periodic schedules
2.2 CXPI Bus Access Method
The CXPI protocol is based on a single master and multiple slave communication systems and supports two
methodologies about how and when data is transferred: Event trigger method and Polling method. In both
communication methods, only the master node provides the clock to the communication bus and all slave nodes
connected to the bus receive the clock from the communication bus and use it for communication processing. Only one
of the two methods can be implemented in all nodes connected to the CXPI communication bus:
▪
Event Trigger method: Each node can freely issue the “PID” field, if idle state of the communication bus is detected.
If several nodes transmit the PID field at the same time and the PID field collides on the communication bus, and
non-destructive arbitration is performed, then the highest priority PID field is transmitted to the communication bus.
▪
Polling method: Master node can freely issue a “PID” field to request a response from the slave nodes. Slave node
can only issue the “PID” field after receiving PTYPE sent from the master node.
The difference between the Event Trigger method and Polling method is that the Polling method requires the master
node to control the network communication by issuing PTYPE field request, which allows all nodes to issue an event
driven PID field on the communication bus. In conclusion, Polling method is suitable for a network which requires high
periodicity communications while Event Trigger method is suitable for the network that requires high responsivity to
events.
In this application note, message frame refers to the entire transmitted frame (including PID/FrameInfo/Data/CRC bytes
in one message frame) whereas byte frame refers to the byte (in terms of PID byte, FrameInfo byte, Data byte, CRC
byte individually). These terminologies will be used throughout this document.
How to Use CXPI Controller in Traveo II Family
www.cypress.com Document Number: 002-24283 Rev. *B 3
2.3 Message Frame Format
The basic CXPI frame has normal and long frames. Due to two different bus communication methods, the basic CXPI
gets an extension by an additional request field (event), usually described as PTYPE field.
Figure 2 illustrates the message frame format based on byte fields, each with a START and STOP bit and the least
significant bit (LSb) first. The Inter Byte Space (IBS) defines the idle time between two bytes within a message frame.
The Inter Frame Space (IFS) defines the period (minimum 20 Tbit) before a next frame can be transmitted by any node.
Figure 2. CXPI Message Frame Format
Header
field /
PID
CXPI bus
Response Field
Data 1 Data 2 Data N CRC
PID
FI
IBS
Normal Frame: N ≤ 12
Long Frame: N ≤ 255
IBS IBS IBSIBS IBS
IFS
DLCEXT
IBS
CRC
IBS
In long frame only
Not supported in HW
EOF
Request
field /
Header
Message frame
PTYPE
Direct-in-periodic Transmission Mode Frame
IBS
The fields of the CXPI Message frame format includes a PTYPE field (only in Polling method), a PID field, a Frame
information field, a Data Length Code Extension (DLXECT, only for Long frame), a Data field, and a CRC field.
PTYPE Field (only in Polling Method)
The 8-bit Protected Type field (PTYPE), only applicable in the Polling method, corresponds to a PID field with the
identifier value 0x00 (0x80 including parity bit). The master node sends a PTYPE byte to allow all slave nodes to send
a request field for this time slot.
Protected Identifier (PID) Field
The request field (header) consists of an 8-bit PID field, which contains a 7-bit frame identifier and a 1-bit odd parity
over the frame identifier.
Frame Information (FI) Field
As the first byte field of the response, the FI field provides information on Data Length Code (DLC), Network
Management (NM), and a frame Counter (CT).
Data Length Code Extension (only for Long frame)
A long frame can have up to 255 data bytes. In this case, the DLC of the FI field must be set to 15 and the DLCEXT
field will be present to indicate the number of data bytes in the message frames.
Data Field
The Data field can be transmitted by every node. In the normal frame, the Data field is present when DLC > 0, and can
be a maximum of 12 bytes long. In the long frame, the Data field will be present when DLC_EXT > 0 and the maximum
length is 255 bytes.
Cyclic Redundancy Check (CRC) Field
The end of a message frame consists of a CRC field and is accessible by the CRC register. The CRC length differs for
normal and long frames. For the normal frame, an 8-bit CRC polynomial is computed over the PID, FI, and Data fields.
For a long frame, a 16-bit CRC polynomial is calculated over the PID, FI, DLCEXT, and Data fields. The PTYPE field
is not included in the CRC calculation.
How to Use CXPI Controller in Traveo II Family
www.cypress.com Document Number: 002-24283 Rev. *B 4
3 CXPI Controller in Traveo II
This section gives an overview of the CXPI Controller in Traveo II family.
Figure 3 shows the block diagram of CXPI Controller in Traveo II. The CXPI channels are part of a common CXPI
module. Each channel has its own control, status registers, and interrupts. The total number of available CXPI channels
depends on the device variant. For details, see the device datasheet.
Figure 3. CXPI Block Diagram
CXPI Module Block
Test Registers
clk_peri
AHB
From PERI/PCLK
CXPI Channel [i]
CXPI IO
Signal
Router
Channel
Registers
cxpi_interrupts_[i]_IRQn
cxpi_en_out[i]
cxpi_rx_out[i]
cxpi_rx_in[i]
From/To IOSS/HSIOM
cxpi_tx_out[i]
cxpi_tx_in[i]
AHB Slave IF
TCPWM_TO_CXPI_TR[i]
CXPI_TR_tx_REQ[i]
CXPI_TR_tx_REQ[i]
Trigger to P-DMA
Trigger from TCPWM IP
PCLK_CXPI_CLOCK_CH_EN[i]
Definition:
i: channel
CH_NR: max. channel number
FIFO
CXPI
Controller
PCLK_CXPI_CLOCK_CH_EN[i]
clk_peri
cxpi_en_in[i]
cxpi_en_out_en[i]
cxpi_tx_out_en[i]
cxpi_rx_out_en[i]
3.1 Mode of Operation
The CXPI Controller in the Traveo II family MCU supports CXPI communication protocol in two operation modes: NRZ
mode and PWM mode.
NRZ mode is associated with CXPI controller interfacing with an external transceiver chip that has PWM
encoder/decoder logic.
PWM mode is associated with CXPI controller interfacing with an external driver/receiver chip that level shifts the
3.3 V or 5 V signaling to signaling at CXPI bus voltage without changing the encoding of the signal.
Master Node
▪
NRZ mode: When the CXPI channel is the master node (CTL0.MASTER = 1) and the CXPI transceiver does the
PWM bus signal encoding, the channel generates only the NRZ signal. As the channel does not provide the CXPI
clock signal, the clock must be generated by another module (for instance, TCPWM) separately.
▪
PWM mode: The PWM mode must be selected for the CXPI channel to process PWM signals. The PWM encoding
and decoding is done in the CXPI channel. Hence, additional device is not needed to generate the clock on the
CXPI bus.
Slave Node
▪
NRZ mode: When the CXPI channel is a slave node (CTL0.MASTER = 0) and the CXPI transceiver does the PWM
bus signal encoding/decoding, then the module must process NRZ signals.
▪
PWM mode: To process PWM signals directly, the CXPI module must be configured to the PWM mode.
How to Use CXPI Controller in Traveo II Family
www.cypress.com Document Number: 002-24283 Rev. *B 5
3.2 Baud Rate and Sampling Concept
3.2.1 Baud Rate
The CXPI channel uses a fixed oversampling of 400. This means that the CXPI channel clock’s frequency is 400 times
the required CXPI interface frequency, i.e. baud rate of the CXPI channel. For details of sampling concept, see the
“Clock Extension Peripheral Interface (CXPI)” chapter of the Architecture TRM.
The baud rate can be configured for each channel individually. Relationship between the target baud rate and the clock
divider is shown in Equation 1.
Equation 1
Here,
▪
: Peripheral clock shown as PCLK_CXPI_CLOCK_CH_EN in Figure 3
▪
: Target baud rate
▪
: Peripheral Clock Divider for dedicated CXPI channel
To achieve the target baud rate with permitted relative tolerance of the nominal CXPI bit time, you can apply a fractional
clock divider.
Example:
Equation 2 shows an example of the divider setting value, when the peripheral clock is 80 MHz and the target baud
rate is 19.2 kbps (19.2 kHz).
Equation 2
To have the nearest divider value, choose a 16.5-bit divider with an integer divide value of 10 and a fractional divider
of 13, which has a divider value of
Equation 3
and generates
Equation 4
Applying the fractional divider results in a relative bit time tolerance of 0.1% while applying an integer divider of 10 or
11 results in relative bit time tolerance of 4.2% and 5.3% respectively.
For details on the clock divider settings and the clock tree, see the Clock System chapter in the Architecture TRM.
3.2.2 Sampling Concept
When transmitting, CXPI channels provide two registers, CTL1.T_LOW1 and CTL1.T_LOW0, to configure the low count
of logic ‘1’ and ‘0’ respectively. CTL1.T_LOW1 and CTL1.T_LOW0 indicate the number of clocks per CXPI channel to
drive a '0' at CXPI bus before releasing it to indicate a logical '1' and a logical ‘0’ respectively.
When receiving, the CXPI channel starts counting after the detection of the falling edges on the RX signal and the
register CTL1.T_OFFSET indicates value of offset that is used for sampling the RX signal.
As described before, the CXPI channel uses a fixed oversampling of 400, meaning 1 Tbit is equivalent to 400 samplings.
To achieve the target width of transmission low level when outputting logical value “1” and “0” and the sampling point
of RX signal, set value of the registers CTL1.T_LOW1, CTL1.T_LOW0, and CTL1.T_OFFSET as shown in Equation 5,
Equation 6, and Equation 7.
Equation 5
How to Use CXPI Controller in Traveo II Family
www.cypress.com Document Number: 002-24283 Rev. *B 6
Equation 6
Equation 7
Here,
▪
: Width of transmission low level when outputting logical value “1”
▪
: Width of transmission low level when outputting logical value “0”
▪
: “cxpi_rx_in” sampling point
Example:
Table 2 shows the sample values set for the registers CTL1.T_LOW1, CTL1.T_LOW0, and CTL1.T_OFFSET to satisfy
timing parameters shown in Table 3.
Table 2. Timing Parameters
Item
Value
Table 3. Values of CTL1.T_LOW1, CTL1.T_LOW0, and CTL1.T_OFFSET
Item
Value
CTL1.T_LOW1
102
CTL1.T_LOW0
177
CTL1.T_OFFSET
118
3.3 CXPI Message Transmission Commands and Interrupt Events
3.3.1 Message Transfer Operation
CXPI controller supports different message types such as transmission and reception of header/response. Message
transfer processing is done by command sequences. Every command is listed in the CMD register.
Header Field Transmission/Reception supporting commands:
▪
CMD.RX_HEADER (C.RXH): This command is used to enable PTYPE and normal PID field reception.
▪
CMD.TX_HEADER (C.TXH): This command is used to request PTYPE and normal PID field transmission.
Response Field Transmission/Reception supporting commands:
▪
CMD.RX_RESPONSE (C.RXR): This command is used to enable the response field reception.
▪
CMD.TX_RESPONSE (C.TXR): This command is used to request response field transmission.
IFS check supporting command:
▪
CMD.IFS_WAIT (C.IFS): This command is used to direct HW to check bus idleness before transmitting or receiving
header.
The use case for the combination of commands to transmit/receive message frames is shown in Table 4 with
abbreviation of commands is shown along with the commands above.
How to Use CXPI Controller in Traveo II Family
www.cypress.com Document Number: 002-24283 Rev. *B 7
Table 4. Combination of Commands 1
Transfer
Method
Master/Slave
Configuration
No.
Transaction
Setting for {C.IFS,
C.TXH, C.RXH,
C.TXR, C.RXR}
Description
Event
Trigger
Master/Slave
1
Transmit both header
(PID) and response
{1, 1, 1, 1, 1}
Master/slave in Event Trigger method uses
this combination to transmit both header (PID)
and response
In this case, HW will check for IFS before
transmitting header and response.
CMD.RX_HEADER and
CMD.RX_RESPONSE are set to 1 to
anticipate receiving PID and response while
checking the duration of bus idleness and
receiving response if arbitration is lost.
2
Transmit header (PID)
and receive response.
{1, 1, 1, 0, 1}
Master/slave in Event Trigger method uses
this combination to transmit header (PID)
CMD.RX_HEADER is set to 1 to anticipate
receiving PID while checking the duration of
bus idleness.
3
Receive both header
(PID) and response
{0, 0, 1, 0, 1}
Enable header and response reception
immediately.
4
{1, 0, 1, 0, 1}
Setting CMD.IFS_WAIT = 1 can make HW
wait for CLT0.IFS before enabling header and
response reception.
5
Transmit response only
{0, 0, 0, 0, 1}
Master/slave in Event Trigger method uses
this combination to transmit response after
receiving relevant PID
Polling
Master
6
Transmit PTYPE and
receiving header (PID)
and response
{1, 1, 1, 0, 1}
Master in Polling method uses this
combination to transmit PTYPE then receive
PID and response
7
Transmit both header
(PID) and response
{1 or 0, 1, 0, 1, 1}
Master in Polling method uses this
combination to transmit both header (PID) and
response.
Setting CMD.IFS = ‘1’ is to make sure that IFS
is checked before transmitting header but is
not mandatory.
CMD.IFS is set to 0 if master transmits PID
after transmitting PTYPE.
8
Transmit header (PID)
and receiving response
{1 or 0, 1, 0, 0, 1}
Master in Polling method uses this
combination to transmit PID and receive
response.
CMD.IFS is set to 0 if master transmits PID
after transmitting PTYPE
9
Transmit response only
{0, 0, 0, 0, 1}
Master in Polling method uses this
combination to transmit response
1
See the “Clock Extension Peripheral Interface (CXPI)” chapter of the Architecture TRM for details on the priority of these commands.
How to Use CXPI Controller in Traveo II Family
www.cypress.com Document Number: 002-24283 Rev. *B 8
Transfer
Method
Master/Slave
Configuration
No.
Transaction
Setting for {C.IFS,
C.TXH, C.RXH,
C.TXR, C.RXR}
Description
Polling
Slave
(ensure
CTL0.RXPIDZE
RO_CHECK_E
N=1) 2
10
Transmit header (PID)
and response
{0, 1, 0, 1, 1}
Slave in Polling method uses this combination
to transmit both PID and response
CMD.RX_RESPONSE is set to 1 to anticipate
receiving response after arbitration is lost.
11
Receive header (PTYPE
and PID) and response
{0, 0, 1, 0, 1}
Slave in Polling method uses this combination
to receive PTYPE/PID and response
12
Transmit response only
{0, 0, 0, 0, 1}
Slave in Polling method uses this combination
to transmit response
3.3.2 Interrupt Events
Each CXPI channel has a dedicated set of interrupt registers: INTR, INTR_SET, INTR_MASK, and INTR_MASKED. In
general, INTR registers are the interrupt event logging registers that are set by HW and cleared by SW (as part of the
interrupt service handler).
Software uses INTR_SET register to set INTR register for testing purpose. Writing ‘1’ into a bit of this register will set
the corresponding bit of INTR register.
The INTR_MASK register is used to mask interrupt sources. Only the interrupt sources with their masks enabled,
meaning corresponding bit in INTR_MASK register is set to ‘1’, can trigger the interrupt.
The INTR_MASKED register is bitwise and between the INTR and INTR_MASK. This register allows SW to read the
status of all mask-enabled interrupt causes with a single load operation.
These interrupt causes are grouped as either functional interrupts or error reporting interrupts. The following are the
functional interrupt causes:
▪
TX_HEADER_DONE: Transmission of frame header is completed.
▪
TX_RESPONSE_DONE: Transmission of frame response is completed.
▪
TX_WAKEUP_DONE: Transmission of wake up is done.
▪
TX_FIFO_TRIGGER: TX FIFO’s number of used slot is less than TRIGGER_LEVEL.
▪
RX_HEADER_DONE: Reception of frame header is completed and will be set only if reception of response is
completed.
▪
RX_HEADER_PID_DONE: This bit is set when reception of frame header is completed without waiting for the
completion of reception of response.
▪
RX_RESPONSE_DONE: Reception of frame response is completed.
▪
RX_WAKEUP_DETECT: Falling edge of RX pin in Sleep mode is detected.
▪
RX_FIFO_TRIGGER: RX FIFO’s number of used slot is greater than TRIGGER_LEVEL.
▪
TXRX_COMPLETE: HW sets this field to '1', when message frame ends after End of Frame (EOF) is confirmed
and TX/RX_DATA_LENGTH_ERROR=0.
▪
TX_HEADER_ARB_LOST: HW sets this field to '1', when it detects arbitration is lost after the number of retries
has exceeded the maximum allowed retries defined in CTL2.RETRY.
▪
TIMEOUT: HW sets this field to '1', when the transmitted/received IBS within a message frame exceeds
CTL2.TIMEOUT_LENGTH.
2
CTL0.RXPIDZERO_CHECK_EN = ‘1’ makes HW (slave) does not clear CMD.RX_HEADER and HW is able to continue receiving header coming after
PTYPE.
Loading...