AN52701 PSoC® 3 and PSoC 5LP – Getting Started with Controller Area Network (CAN) Author: Ranjith M Associated Project: Yes Associated Part Family: All PSoC 3 and PSoC 5LP parts with CAN Software Version: PSoC ® Creator 2.1 SP1 Related Application Notes: None If you have a question, or need help with this application note, contact the author at [email protected]. This application note introduces the basic concepts of Controller Area Network (CAN) and demonstrates how CAN bus communication is implemented using PSoC® 3 and PSoC 5LP. Contents Introduction Introduction ....................................................................... 1 Why Use CAN? ............................................................ 2 Why Use PSoC? .......................................................... 2 CAN Basics ....................................................................... 2 Physical Layer .............................................................. 2 Transfer Layer .............................................................. 2 Bus Arbitration .............................................................. 3 Error Management in CAN ........................................... 5 CAN in PSoC .................................................................... 5 Hardware ...................................................................... 5 The CAN Component ................................................... 7 PSoC Creator Projects ................................................. 7 Firmware .................................................................... 13 Implementing the Hardware ............................................ 15 Working with a CAN Analyzer .................................... 16 Example Projects ............................................................ 16 Examples 1 and 2: Simplex Communication .............. 16 Examples 3 and 4: RTR feature in CAN ..................... 18 Summary ......................................................................... 20 Appendix A ...................................................................... 21 Appendix B ...................................................................... 22 Worldwide Sales and Design Support ............................. 24 Controller Area Network (CAN) is a serial communication protocol developed by Robert Bosch GmbH in the early 1980s. This protocol was initially developed for automotive applications, for communications between subsystems with no central control. CAN is also being adopted in areas such as embedded systems (CANOpen) and factory automation (DeviceNet). CAN was standardized by the ISO in 2003 (ISO 11898-1:2003). www.cypress.com This application note introduces the basic concepts of the CAN protocol and demonstrates how CAN bus communication can be implemented using PSoC® 3 and PSoC 5LP. Four examples are included with this application note. Examples 1 and 2 together illustrate a simplex communication between two PSoCs. Examples 3 and 4 together demonstrate the Remote Transmission Request (RTR) feature of CAN. This application note assumes that you are familiar with developing applications using PSoC Creator for PSoC 3 or PSoC 5LP. If you are new to PSoC 3 or PSoC 5LP, introductions can be found in AN54181, Getting Started with PSoC 3 and AN77759, Getting Started with PSoC 5LP. If you are new to PSoC Creator, see the PSoC Creator home page. Document No.001-52701 Rev. *I 1 PSoC® 3 and PSoC 5LP - Getting Started with CAN Figure 1. Nodes Connected to a CAN Network CAN networks are designed for short messages with data length not more than 8 bytes, and a bit rate up to 1 Mbps. The CAN protocol offers several advantages over other serial communication protocols: CAN is a message-based protocol; CAN network nodes are not assigned specific addresses. This provides flexibility to add or remove a node from the network without affecting the rest of the network. In addition, if one of the nodes fails, the others continue to work and communicate properly. CAN messages can be prioritized. The CAN network has system-wide data consistency, that is, if a message is corrupt at a receiving node, the message is not accepted by any of the other receiving nodes. CAN has five levels of error checking, to ensure reliable traffic and data integrity. CANH 120Ω 120Ω Why Use CAN? CANL CAN Node A CAN Node B CAN Node C The CAN bus carries differential signals, as Figure 2 shows. A '1' is represented by both lines at approximately the same voltage (typically 2.5 V). A '0' is represented by a 1.5 V to 3 V difference in voltage between the lines. A ‘1’ is called a recessive bit and a ‘0’ is called a dominant bit. Figure 2. CAN Bus Voltages 1 Bit Pattern 0 Corrupted messages are automatically retransmitted as soon as the bus is idle again. V CAN Bus Voltages Why Use PSoC? 3.6 CANH 2.5 PSoC 3 and PSoC 5LP integrate CAN functionality along with configurable analog, programmable digital, memory, and a central processor on a single chip. PSoC Creator provides built-in application programming interfaces (APIs) to abstract common tasks. Moreover, all PSoC Creator components, including the CAN component, can be easily configured using a GUI, rather than writing C code for them. See application note AN70630 - Event Data Recorder with Controller Area Network using PSoC 3 and nvSRAM for a system-level application of the CAN component. 1.4 RECESSIVE 0 CANL DOMINANT RECESSIVE The CAN protocol specifies that if recessive and dominant bits are simultaneously applied to the CAN bus by two different nodes, the bus must have the dominant bit. This can be related to a wired AND analogy – the bus does not have a recessive bit unless all nodes drive recessive bits. While in an idle state, the bus holds recessive bits. Transfer Layer CAN Basics This section explains the basics of the CAN protocol. A more detailed description protocol is available in the CAN specification. If you are familiar with CAN and want to see how it is implemented in PSoC 3 and PSoC 5LP, see the section CAN in PSoC. Physical Layer Figure 1 shows how devices connect to a CAN bus. The CAN bus consists of two physical lines, CANH and CANL. The CAN bus is typically terminated with a 120-Ω resistor at each end. Any node can start transmitting a message when the CAN bus is idle. Messages are transmitted through the bus in a fixed format called a frame. CAN defines four frame types: Data Frame - carries data from a transmitter to a receiver Remote frame - transmitted by a CAN node to request transmission of a data frame Error Frame - transmitted by any unit on detecting an error on the bus Overload Frame - used to provide extra delay between the preceding and the succeeding data or remote frame See Appendix A for format details for these frames. www.cypress.com Document No.001-52701 Rev. *I 2 PSoC® 3 and PSoC 5LP - Getting Started with CAN A data frame is composed of seven-bit fields, as Figure 3 shows. Figure 3. CAN Data Frame Data Frame 11-bit identifier R T R I D E R0 Data Length Count Arbitration Field Control Field 0 to 8 Bytes Data Field CRC Field Start of Frame ACK Field Arbitration Field: The arbitration field of a data frame consists of two parts: an IDENTIFIER and a Remote Transmission Request (RTR) bit. The identifier is used to describe the meaning of the data carried by the data frame. Each node on the bus checks the identifier and decides whether to accept the message. Based on the length of the identifier field, two types of CAN messages are defined: standard and extended. A standard CAN message has an 11-bit identifier and an extended CAN message has a 29-bit identifier. Thus, a standard CAN data frame can support 211 different types of messages and an extended CAN data frame can support 229 different messages. The RTR bit is used to indicate whether the given frame is a data frame or a remote frame. The RTR bit is set ‘dominant’ in a data frame and ‘recessive’ in a remote frame. Control Field: The control field of the data frame defines the number of data bytes in the data field. The control field is six bits long, with four bits for data length and two bits reserved for future expansion. www.cypress.com End of Frame Data Field: The data field contains the data to be communicated. CRC Field: The Cyclic Redundancy Check (CRC) field is for error checking. This field contains a bit sequence, which is used to determine if the received frame contains any errors. The ACK field is used by the receiving nodes to acknowledge that the frame was correctly received. A node acting as a receiver can request the transmission of a particular message from its source. This is achieved with the help of a remote frame. A remote frame is similar to a data frame except that it does not have a data field. Bus Arbitration If multiple nodes try to transmit at the same time, bus arbitration is done using identifier bits, as Figure 4 shows. Using the property of dominant bits described previously, after transmitting a bit on to the bus, each node checks if the bus state is the same as the bit that it transmitted. If they are the same, each node transmits the next bit. If they are different, the node stops transmitting and starts to receive the message on the bus. This is called the ‘listen only’ mode. Document No.001-52701 Rev. *I 3 PSoC® 3 and PSoC 5LP - Getting Started with CAN Figure 4. Bus Arbitration in CAN 10 9 8 Node A Node B 7 6 5 4 3 2 1 0 S O F R T R S O F Listen Only Node C S O F Bus State S O F Control Data Listen Only R T R Control Data Since each node reads back the bus after transmitting each bit, the bit duration must be larger than the largest propagation delay in the bus, to ensure that a collision does not go undetected. Therefore, the transmitted bit is read back after a delay to compensate for the propagation delay. The instant at which the bus is read back is called a "sample point", as Figure 5 shows. The amount of time required to transmit a single bit is called the "bit time". In the CAN specification, bit time is expressed in terms of time quanta (TQ). A time quantum is a fixed unit of time derived from the oscillator period, as Figure 5 shows. The oscillator frequency is divided by a factor called Baud Rate Prescaler (BRP) to obtain the CAN clock frequency. Figure 5. Derivation of Bit Time from Oscillator Oscillator Baud Rate Prescaler (BRP), user definable CAN Clock 1 Bit Time 10 - 20 TQ, user definable CAN Bit Period Sync-Seg (fixed) 1 TQ TSEG2 N2 TQ, user definable TSEG1 N1 TQ, user definable Sample Point At the start of the Sync Segment, or first TQ, the transmitter begins to drive the bit on to the bus. The transmitter continues to drive the bus throughout the bit time, and after a defined amount of time samples the bus for a collision. The time is determined by setting parameters TSEG1 and TSEG2; see Figure 12 on page 8. Generally, the sample point should be 60% to 80% of the bit time. www.cypress.com Document No.001-52701 Rev. *I 4 PSoC® 3 and PSoC 5LP - Getting Started with CAN Error Management in CAN A CAN node detects and handles five types of errors: Bit error - A bit error is detected by the transmitter when it finds that the bit transmitted and the bit on the bus are not the same. Form error - A form error is detected when there is any deviation in the message fixed format. A data length count (DLC) greater than 8 bytes is also considered a form error. Stuff error - Whenever a transmitter detects five consecutive bits of identical value in the bit stream to be transmitted, it automatically inserts a complementary bit into the stream. This is called bit stuffing. A stuff error is detected when six consecutive bits of identical value are detected. receive errors, which are incremented after detecting corresponding errors. Depending upon the value of the error counters, a CAN node can be in three different states: Error Active State - A node is in the "error active" state if the transmit or receive error counters are less than or equal to 127. An error active node can have normal bus communication. Error Passive State - A node is in the "error passive" state if the transmit or receive error counter value is greater than or equal to 128. An error passive node can have normal bus communication. Bus Off State - A node is in the "bus off" state if the transmit error counter is greater than or equal to 256. A node that is in bus off does not have any bus communication. It has no effect on the bus. CRC error – A CRC error is detected when the value indicated by the CRC field of a frame does not match the frame's expected CRC value. CAN in PSoC Acknowledge error - An acknowledge error is detected by the transmitter if an acknowledgement (a ‘dominant’ bit) is not obtained during the acknowledge field of frame. The CAN block in PSoC 3 and PSoC 5LP, shown in Figure 6 on page 6, is compliant with the CAN 2.0a and 2.0b standards. However, it requires an external transceiver to level shift the output voltages and to make it compatible with the CAN protocol. The TJA1050 from NXP or the SN65HVD1050-EP from TI can be used as an external transceiver. These devices translate between the bit pattern and bus voltages, as Figure 2 on page 2 shows. Bit errors and acknowledge errors are detected by the transmitter, and stuff errors, CRC errors, and form errors are detected by the receiver. If a message fails any of these error detection methods, the message is not accepted and the receiving node generates an error frame. The transmitting node, then, re-transmits the message until it is received correctly. Hardware With this application note, the Cypress kit CY8CKIT-017 uses the TJA1050 as the external transceiver, as Figure 7 on page 6 shows. If a faulty node hangs the bus by continuously retransmitting an error frame, its transmit capability is removed after the number of errors equals the error limit. Each node maintains error counters for transmit and www.cypress.com Document No.001-52701 Rev. *I 5 PSoC® 3 and PSoC 5LP - Getting Started with CAN Figure 6. CAN Block Diagram Memory Buffer (SRAM) CAN Module Memory Arbiter Receive Message Handler Transmit Message Handler To CPU/PHUB Advanced Peripheral Bus (APB) Coupler CAN Bus CAN Framer Interrupt Controller Status and Configuration Control and Command Figure 7. Hardware Connections for Implementing CAN Network 5V 5 V CY8C3866AXI PSoC 3 VDD VDD CY8CKIT-017 TX C_TX RX C_RX Tx_En C_EN CAN_H CAN_L CY8CKIT-017 C_TX TX C_RX RX C_EN Tx_En CAN_H CAN_L VSS VSS www.cypress.com CY8C3866AXI PSoC 3 Document No.001-52701 Rev. *I 6 PSoC® 3 and PSoC 5LP - Getting Started with CAN The CAN Component PSoC Creator Projects Figure 8 shows how the CAN component is displayed on the PSoC Creator schematic. Do the following steps to build projects to demonstrate basic CAN: Figure 8. CAN Component in PSoC Creator. 1. Open PSoC Creator and create a new project (File > New > Project). Name the project ‘Receiver’. 2. Drag and drop the CAN Controller Macro from the Component Catalog to the TopDesign schematic, as Figure 9 shows. Figure 9. CAN Controller Macro in Component Catalog PSoC offers two different modes for CAN communication: Full CAN and Basic CAN. The following are the important differences between a full CAN message and a Basic CAN message: A Full CAN communication can be easily set up with the help of a GUI, with a very limited amount of programming involved. Basic CAN requires all of the parameters to be set in firmware. Full CAN uses hardware for message filtering. Basic CAN requires the CPU to be interrupted each time a message is received, to determine whether it is accepted or not. Full CAN can only receive a single type of message for each mailbox1 whereas Basic CAN can accept messages with a range of identifiers for each mailbox. The following section explains how to configure the CAN component for a Full CAN communication. The steps below describe how to configure two PSoCs, each in a separate development kit (DVK). The CAN component in one PSoC is configured as the transmitter and the CAN component in the other PSoC is configured as the receiver. 3. Drag and drop the character LCD component from the component catalog to the TopDesign schematic. This is available under the folder 'Display'. Figure 10 shows the complete schematic. Figure 10. Completed TopDesign Note Only the options relevant to this application note are described. See the CAN component datasheet for a detailed description of all the options available with the CAN component. 1 A mailbox is a set of input / output buffers for receiving and transmitting CAN messages. www.cypress.com Document No.001-52701 Rev. *I 7 PSoC® 3 and PSoC 5LP - Getting Started with CAN 4. Double-click on the CAN component in the TopDesign to open the configuration window. C AN G e n e r a l C o n f i g u r a t i o n : Figure 11 shows the general configuration tab for the PSoC Creator CAN component. C AN T i m i n g C o n f i g u r a t i o n : Figure 12 shows the timing configuration tab for the CAN component. Figure 12. Timing Settings Tab for CAN component Figure 11. General Settings Tab for CAN Component 9. 5. Ensure that the Add Transceiver Signal checkbox is checked. This is enabled by default. The Add Transceiver Signal option in the General Configuration tab enables/disables the tx_en signal in the CAN component. This signal is used to connect to the enable pin of the external transceiver. 6. Set the Transmit Buffer Arbitration to be ‘RoundRobin’. The Round Robin option ensures that all transmit mailboxes are given equal opportunity to transmit, whereas the fixed priority option assigns priorities to mailboxes according to which messages are transmitted. 7. Set the Bus-Off Restart method to be ‘Manual’". Bus-Off restart can be done either manually or automatically, monitoring the number of transmit errors. 8. Select the CAN Bus Synchronization Logic to be 'R' to 'D'. A clock signal is not transmitted in a CAN network. Instead, clocks of all the receiving nodes are synchronized at the falling edge of the start of frame (SOF) bit sent by the transmitter. Subsequent edges are also used for synchronizing the clocks, to accommodate for the small drifts in clocks between different nodes. Set the baud-rate to be 500 Kbps. This automatically modifies the values as shown in Figure 12. The baud rate determines the speed of communication between the devices. It can be as high as 1 Mbps. All CAN nodes on a bus must operate at the same baud rate. Note Selecting the baud rate only provides a list of possible timing parameters in the table (see Figure 12). You must double-click on a row in the table to update the parameters in the respective fields. 10. Double-click on the row with BRP = 2, Time Quantum = 16, and Sample Point = 75 (see Figure 12) to add these values to the "Settings". For best performance, select a row with a Sample Point value between 60 and 80 and a Variance of 0. 11. Set the Synchronization Jump Width (SJW) to be 1 and Sample Mode to be "1-Sample". SJW is the number of time quanta that a sample point is allowed to vary from its mean position. This value must be less than or equal to both TSEG1 and TSEG2 in Figure 5 on page 4. The sample mode is the number of samples that are taken to determine the state of the bus. A single sample mode or 3-sample mode may be chosen here. The synchronization can be done on either recessive to dominant ('R' to 'D') transitions or on both edges (recessive to dominant and dominant to recessive). www.cypress.com Document No.001-52701 Rev. *I 8 PSoC® 3 and PSoC 5LP - Getting Started with CAN C AN I n t e r r u p t C o n f i g u r a t i o n : Figure 13 shows the interrupt settings tab for the CAN component. Use this tab to enable or disable interrupts on a number of events. If an interrupt is enabled, PSoC executes an Interrupt Service Routine (ISR) when that event occurs. The Message Received and Bus Off State interrupts are selected by default. The Message Receive interrupt automatically calls the ReceiveMsgx() function in CAN_TX_RX_func.c. C AN R e c e i v e B u f f e r : The CAN component has 16 input buffers, or mailboxes, for receiving messages. Thus the CAN component can receive at most 16 different CAN message types. The mailboxes are numbered from 0 to 15 by default and can be replaced with any name of your choice. To do this, select the "Full" mode, as Figure 14 shows. Selecting Full mode enables other configurable options in the row. Figure 14. Receive Buffer Settings for the CAN component Figure 13. Interrupt Settings Tab for CAN Component 12. Make sure that the check boxes "Enable Interrupts", "Message Received", and "Bus Off State" are checked, to enable these interrupts. All other boxes should be unchecked. 13. Select the checkboxes, as Figure 14 shows, to enable a Full mailbox with ID 0x2FF. The ID field is used to define the identifier for the message to be received in the corresponding mailbox, and can be set to any 11bit value. 14. Check the IRQ box to trigger an interrupt when a message is received in that mailbox. This completes configuration of the CAN component on the receiver side. The transmit buffers need not be configured in this case, since this node does not need to transmit a message. www.cypress.com Document No.001-52701 Rev. *I 9 PSoC® 3 and PSoC 5LP - Getting Started with CAN C AN T r a n s m i t B u f f e r : Now, let us configure the transmitter side. Since we do this for the other PSoC, we need to create another project for that PSoC. 15. Add another project to the Workspace: Right-click on the Workspace name inside the Workspace Explorer window and select the option Add > New Project. Name this project ‘Transmitter’. 16. Drag and drop the CAN Controller Macro into the TopDesign of this project. Configure the CAN component as described in steps 3 to 12, same as the receiver side. The Transmit Buffers tab is used to configure the transmit mailboxes, as Figure 15 shows. A transmit mailbox can be either Full or Basic. Selecting Full mode enables other configurable options in the row. Pin Configurations The steps in this section apply to both the Receiver and Transmitter projects. Let us now add and configure the pins in the projects. The Tx_1 and Rx_1 pins were included as part of the CAN macro in step 2. We need to add a third pin, as Figure 10 shows. 18. Drag and drop a Digital Output Pin on to the TopDesign schematics of both the projects, as Figure 10 and Figure 16 show. Connect this pin to the tx_en output of the CAN component. This pin is used to enable the external transceiver. Figure 16. Locating the Digital Output Pin Figure 15. Transmit Buffer Settings for CAN Component 17. Select the checkboxes as Figure 15 shows, to enable a Full mailbox with ID 0x2FF, same as the receiver side. The Data Length Count (DLC) field is 1 because we only need to transmit one byte. 19. Open each project's design wide resources (.cydwr) file by double-clicking on it in the Workspace Explorer, as Figure 17 shows. www.cypress.com Document No.001-52701 Rev. *I 10 PSoC® 3 and PSoC 5LP - Getting Started with CAN Clock Configurations The steps in this section apply to both the Receiver and Transmitter projects. Figure 17. Locating the .cydwr file The CAN protocol does not transmit a clock to synchronize the bits. Synchronization between nodes is done for every bit transmitted, during the Sync Segment, as Figure 5 on page 4 shows. This requires the use of a highly accurate oscillator for baud rates greater than 125 Kbps. The CAN protocol specifies that the clock accuracy must be less than or equal to 0.5%. An error less than 0.1% can be achieved in PSoC by using an external crystal. The clock tree dialog in the design wide resources file (that is, the file with extension .cydwr) is used to configure this. 21. Open the design wide resources file, as Figure 18 shows. From the Clocks tab, click Edit Clocks. The clock tree dialog opens. 22. Enable the crystal - click the check box XTAL on the top left of the clock tree. Click the configure button and enter 24 MHz for the crystal frequency. 20. Assign the ports for each of the pins as Table 1 shows. Table 1. Pin Assignments Pin CY8CKIT-001 CY8CKIT-030 Rx_1 P3[4] P3[4] Tx_1 P3[3] P3[3] Pin_1 P3[2] P3[2] LCD_Char_1 P2[6:0] P2[6:0] www.cypress.com 23. Select XTAL as the IMO source. Do not change the other settings. 24. If your kit does not already have it, connect a 24-MHz crystal and two capacitors to pins P15[0] and P15[1]. See a PSoC 3 or PSoC 5LP datasheet for details. Document No.001-52701 Rev. *I 11 PSoC® 3 and PSoC 5LP - Getting Started with CAN Figure 18. Clock Tree Configuration www.cypress.com Document No.001-52701 Rev. *I 12 PSoC® 3 and PSoC 5LP - Getting Started with CAN Firmware The steps in this section apply to both the Receiver and Transmitter projects. A small amount of firmware must be added to each project. 25. Build each project by selecting the menu Build > Build All Projects. The CAN component and other API files are automatically generated. 27. Open the CAN_1_TX_RX_func.c file in the Transmitter project by double-clicking the file name inside the Workspace Explorer, as Figure 20 shows. This file is generated after the project is built. Figure 20. Locating the CAN_1_TX_RX_func.c file 26. Open the main.c file of the transmitter project by double-clicking the file name inside the Workspace Explorer (see Figure 19). Add the code from Code 1 to the main.c file. Figure 19. Locating the main.c file 28. Navigate to the lines: /* `#START TX_RX_FUNCTION` */ /* `#END` */ Code 1. Transmitter main.c Code 29. Type the following line of code between these lines. #include <device.h> extern uint8 Tx_Data; uint8 Tx_Data = 0; 30. Locate the function CAN_1_SendMsg0() in the same file. Navigate to the code: void main() { CAN_1_Start(); LCD_Char_1_Start(); CyGlobalIntEnable; /* `#START MESSAGE_0_TRASMITTED` */ /* `#END` */ for(;;) /* do forever */ { LCD_Char_1_ClearDisplay(); LCD_Char_1_Position(0,0); LCD_Char_1_PrintNumber(Tx_Data); CAN_1_SendMsg0(); Tx_Data++; CyDelay(500); } 31. Type the following line of code between these lines. CAN_1_TX_DATA_BYTE1(0) = Tx_Data; } www.cypress.com Document No.001-52701 Rev. *I 13 PSoC® 3 and PSoC 5LP - Getting Started with CAN 32. Open the main.c file of the Receiver project by double-clicking on the filename inside the Workspace Explorer. Add the code from Code 2 to the main.c file. Other Firmware Considerations Consider the following points when writing firmware for a CAN component: Code 2. Receiver main.c Code The CAN component needs to be initialized and started in the main.c file before using it. uint8 Rx_Data; Global interrupts should be enabled to service the interrupt requests from the CAN component. void main() { CAN_1_Start(); LCD_Char_1_Start(); CyGlobalIntEnable; To transmit a Full CAN message from a particular transmit mailbox, call the function CAN_TX_SendMsgx(), where x is replaced by the mailbox number and CAN_TX is the name given to the CAN component in the PSoC Creator TopDesign schematic. The necessary functions for transmitting and receiving Full CAN messages are available in the CAN_TX_TX_RX_func.c file. This file is generated when the project is built. #include <device.h> for(;;) /* do forever */ { LCD_Char_1_ClearDisplay(); LCD_Char_1_Position(0,0); LCD_Char_1_PrintNumber(Rx_Data); } } 33. Open the CAN_1_TX_RX_func.c file for the Receiver project by double-clicking the file name inside the Workspace Explorer. This file is generated after the project is built. Refer to the example projects provided with this application note to understand how the firmware is written to configure CAN in PSoC. 34. Navigate to the lines: /* `#START TX_RX_FUNCTION` */ /* `#END` */ 35. Type the following line of code between these lines. extern uint8 Rx_Data; 36. Locate the function CAN_1_ReceiveMsg0() in the same file. Navigate to the code: /* `#START MESSAGE_0_RECEIVED` */ /* `#END` */ 37. Type the following line of code between these lines. Rx_Data = CAN_1_RX_DATA_BYTE1(0); 38. Build both projects and program each of them into the PSoCs in the two kits. The program option is found in the menu Debug in PSoC Creator: Debug > Program. www.cypress.com Document No.001-52701 Rev. *I 14 PSoC® 3 and PSoC 5LP - Getting Started with CAN Implementing the Hardware The PSoC outputs from the CAN component are TX and RX. You must level-translate these outputs to obtain the CANH and CANL signals. The CY8CKIT-017 Expansion Board Kit is used as an external transceiver for level translation for the examples given in this application note. The CAN transceiver IC used in this kit is the TJA1050. The transceiver may be implemented with minimal connections as Figure 25 on page 17 shows, where the CY8CKIT-017 may be replaced by a TJA1050. A detailed figure is shown in Appendix B. CAN requires only two wires for a CAN bus. In the CY8CKIT-017, a standard male-to-male DB9 connector may be used to connect between two CAN nodes, as Figure 21 shows. The cable length between any two CAN nodes in a CAN network should be restricted to the values shown in Table 2. These values are not mentioned in the CAN specification, but are typical values used in a design. Table 2. Typical cable lengths for different baud rates. Baud Rate (in bits per second) Typical Cable Length (in meters) 1 Mbps 40 500 Kbps 100 250 Kbps 200 125 Kbps 500 10 Kbps 6000 Figure 21. CAN Physical Connections www.cypress.com Document No.001-52701 Rev. *I 15 PSoC® 3 and PSoC 5LP - Getting Started with CAN Working with a CAN Analyzer 2. A CAN analyzer is a device used to monitor the data traffic on a CAN bus, for debugging purposes. These devices are available from manufacturers such as Microchip and Peak-system. Figure 22 shows a block diagram illustrating the connection of a USB CAN analyzer to a CAN bus Table 3. Pin Usage for CAN Simplex Transmitter Pin A CAN analyzer also requires software such as PCAN View to be installed on the computer system to which the CAN analyzer is connected. This software interprets the data received by the CAN analyzer and shows it in the application’s interface. Figure 22. USB CAN Analyzer Connected to a CAN Bus CAN Analyzer USB Computer (CAN Analyzer Software) Open the project files and make the correct pin assignments in the .cydwr file. Pin assignments are as shown in Table 3 and Table 4. CANH CANL P2[6:0] P2[6:0] Data_In P0[0] P6[1] RX P3[4] P3[4] TX P3[3] P3[3] Tx_En P3[2] P3[2] Table 4. Pin Usage for CAN Simplex Receiver CAN Node 2 (PSoC with transceiver) Example Projects 3. There are four example projects included with this application note. Examples 1 and 2: Simplex Communication CY8CKIT-030 / CY8CKIT-050 LCD_Tx Pin CAN Node 1 (PSoC with transceiver) CY8CKIT-001 CY8CKIT-001 CY8CKIT-030 / CY8CKIT-050 LCD_Rx P2[6:0] P2[6:0] RX P3[4] P3[4] TX P3[3] P3[3] Tx_En P3[2] P3[2] Build both of the projects. Program CAN_SimplexCommunication_Tx into the first PSoC and CAN_SimplexCommunication_Rx into the second PSoC. Examples 1 and 2, shown in Figure 25 on page 17, demonstrate a simplex communication between two CAN nodes. The CAN_SimplexCommunication_Tx project displays ‘TRANSMITTER’ on the first row of the LCD display. The second row shows the number of key presses registered on the Data_in pin. Example 1 acts as a transmitter. It monitors key presses on a switch and communicates the number of key presses through CAN. Example 2 acts as the receiver. It receives the data and displays it on the character LCD display. The flowcharts shown in Figure 23 and Figure 24 on page 17 illustrate the program flow for these examples. The CAN_SimplexCommunication_Rx project displays ‘RECEIVER’ on the first row of the LCD display. The second row displays the data sent by the first PSoC through CAN. This is the same as the number of key presses shown on the second row of the CAN_SimplexCommunication_Tx project. Follow these steps to set up example projects 1 and 2: 1. Build the system as Figure 25 shows. Two CY8CKIT001 DVKs and two CY8CKIT-017 EBKs may be used. A CY8CKIT-030 or CY8CKIT-050 DVK can also be used instead of a CY8CKIT-001 DVK. www.cypress.com Document No.001-52701 Rev. *I 16 PSoC® 3 and PSoC 5LP - Getting Started with CAN Figure 24. Flowchart for Example 2 (Receiver) Figure 23. Flowchart for Example 1 (Transmitter) Start Start Initialize CAN, LCD and variables Initialize CAN and variables Data Received? N Key press? N Y Y Update LCD Data Increase count by 1 Transmit count and Update LCD Figure 25. Physical Configuration for Examples 1 and 2 CY8C3866AXI PSoC 3 5V (Project#1) 5V CY8C3866AXI PSoC 3 (Project#2) VDD VDD CY8CKIT-017 P3[3] CY8CKIT-017 C_TX CAN_H P3[4] C_RX P3[2] C_EN CAN_L C_TX P3[3] C_RX P3[4] C_EN P3[2] CAN_H CAN_L Switch P0[0] P2[6:0] P2[6:0] VSS 8 8 LCD LCD www.cypress.com VSS Document No.001-52701 Rev. *I 17 PSoC® 3 and PSoC 5LP - Getting Started with CAN Examples 3 and 4: RTR feature in CAN Table 6. Pin Usage for CAN_RTR_Node2 Examples 3 and 4, shown in Figure 28 on page 19, demonstrate the RTR feature of CAN. Example 3 is named Node1 and Example 4 is named Node 2. Node 1 monitors the ADC data input and displays the ADC value on the LCD display. In the event of an RTR request from Node 2, the current value of the ADC is transmitted to Node 2. Node 2 continuously checks for a key press on a switch and issues an RTR request to Node 1 in event of a key press. The ADC data value sent by Node 1 is received by Node 2 and is displayed on its LCD display. Flowcharts shown in Figure 26 and Figure 27 on page 19 illustrate the program flow for these examples. Follow these steps to set up example projects 3 and 4: 1. Build the system as Figure 28 shows. Two CY8CKIT001 DVKs and two CY8CKIT-017 EBKs may be used for this. A CY8CKIT-030 or CY8CKIT-050 DVK can also be used instead of a CY8CKIT-001 DVK, 2. Open the project files and make the correct pin assignments in the .cydwr file. Pin assignments are as shown in Table 5 and Table 6: Table 5. Pin Usage for CAN_RTR_Node1 Pin CY8CKIT-001 3. CY8CKIT-001 CY8CKIT–030 / CY8CKIT-050 LCD P2[6:0] P2[6:0] RTR_In P0[0] P6[1] RX P3[4] P3[4] TX P3[3] P3[3] Tx_En P3[2] P3[2] Build both of the projects. Program CAN_RTR_Node1 into the first PSoC and CAN_RTR_Node2 into the second PSoC. The CAN_RTR_Node1 project displays ‘Node1’ on the first row and the present value of the ADC output on the second row of the LCD display. The CAN_RTR_Node2 project displays ‘Node2’ on the first row of the LCD display. When the RTR_In key is pressed, the first row shows ‘RTR Sent’ and the second row shows the value of the ADC output received from Node1 in response to the RTR. CY8CKIT-030 / CY8CKIT-050 LCD P2[6:0] P2[6:0] ADC_In P0[0] P6[5] RX P3[4] P3[4] TX P3[3] P3[3] Tx_En P3[2] P3[2] www.cypress.com Pin Document No.001-52701 Rev. *I 18 PSoC® 3 and PSoC 5LP - Getting Started with CAN Figure 26. Flowchart for Example 3 (Node 1) Figure 27. Flowchart for Example 4 (Node 2) Start Start Initialize CAN, ADC, LCD and variables Initialize CAN, LCD and variables Get ADC Value Display on LCD N Key Press? RTR Request? N Y Send RTR request Y Transmit ADC Value Value Update on LCD Figure 28. Physical Configurations for Examples 3 and 4 CY8C3866AXI PSoC 3 5V (Project#3) 5V VDD VDD CY8CKIT-017 P3[3] 5V CY8CKIT-017 C_TX CAN_H VIN P3[4] C_RX P3[2] C_EN CAN_L C_TX P3[3] C_RX P3[4] C_EN P3[2] CAN_H CAN_L P0[0] P2[6:0] P0[0] P2[6:0] VSS RTR_Switch 8 VSS 8 LCD LCD www.cypress.com CY8C3866AXI PSoC 3 (Project#4) Document No.001-52701 Rev. *I 19 ® PSoC 3 and PSoC 5LP - Getting Started with CAN For proper operation of these projects, ensure that jumper JP2 of the CY8CKIT-017 is populated. In addition, jumper JP6 of the CY8CKIT-017 should be connected between V5_0 and VDD. A standard male-to-male DB9 connector can be used to connect between two CAN nodes. Two more example projects are available in PSoC Creator Example Projects. Summary CAN is a reliable serial communication protocol used mainly in automotive applications. The protocol allows bidirectional communication between devices and offers a flexible network. Cypress PSoC 3 and PSoC 5LP, along with PSoC Creator, support the CAN 2.0a and CAN 2.0b specifications and offer a user-friendly interface and collection of APIs to set up the CAN network with ease. This application note guides you in implementing CAN with PSoC smoothly. About the Author www.cypress.com Name: Ranjith M Title: Applications Engineer Background: Ranjith graduated from Government Engineering College, Thrissur with a Bachelor's Degree in Electronics and Communications Engineering. Contact: [email protected] Document No.001-52701 Rev. *I 20 ® PSoC 3 and PSoC 5LP - Getting Started with CAN Appendix A STANDARD DATA FRAME ARBITRATION FIELD INTERFRAME SPACE START OF FRAME IDENTIFIER (11 BITS) RTR IDE R0 DLC (4 BITS) DATA (MAXIMUM 8 BYTES) CRC FIELD ACK FIELD END OF FRAME INTERFRAME SPACE CONTROL FIELD EXTENDED DATA FRAME ARBITRATION FIELD INTERFRAME SPACE START OF FRAME IDENTIFIER (11 BITS) SRR IDE IDENTIFIER RTR (18 BITS) R1 R0 DLC (4 BITS) DATA (MAXIMUM 8 BYTES) CRC FIELD ACK FIELD END OF FRAME INTERFRAME SPACE CONTROL FIELD www.cypress.com Document No.001-52701 Rev. *I 21 ® PSoC 3 and PSoC 5LP - Getting Started with CAN Appendix B Interfacing with TJA1050 VDD VCC PSoC P3[2] S P3[3] TXD P3[4] RXD TJA1050 CANH To CAN BUS CANL GND GND www.cypress.com Document No.001-52701 Rev. *I 22 ® PSoC 3 and PSoC 5LP - Getting Started with CAN Document History Document Title: PSoC® 3 and PSoC 5LP - Getting Started with Controller Area Network (CAN) Document Number: 001-52701 Revision ECN Orig. of Change Submission Date Description of Change ** 2710279 ANUP 05/22/09 New application note *A 2763879 ANUP 09/15/09 Updated Figure 2: Basic CAN Frame Schematic *B 2947435 ANUP 06/08/10 Changed document title. Updated to PSoC Creator Beta 4.1 and made the projects PSoC 5 compatible *C 3032350 ANUP 09/17/10 Removed CAN_Init() from example code. Also moved CAN_RegisterInit() APIs after start API in page 10. *D 3174976 ANUP 02/16/2011 Updated Setting Acceptance Filter. Added Code Example. Added CAN Clock Accuracy. *E 3292004 LRDK 06/24/2011 Rewritten in Simplified English. *F 3445166 DASG 11/22/2011 Project updated to PSoC Creator 2.0. Updated template. *G 3756544 RNJT 11/12/2012 Changed title. Complete rewrite of application note. *H 3857178 RNJT 01/03/2013 Major changes in the section CAN in PSoC. *I 4031275 RNJT 06/17/2013 Added note in the CAN Timing Configuration section. www.cypress.com Document No.001-52701 Rev. *I 23 ® PSoC 3 and PSoC 5LP - Getting Started with CAN Worldwide Sales and Design Support Cypress maintains a worldwide network of offices, solution centers, manufacturer’s representatives, and distributors. To find the office closest to you, visit us at Cypress Locations. Products PSoC® Solutions Automotive cypress.com/go/automotive Clocks & Buffers cypress.com/go/clocks Interface cypress.com/go/interface Lighting & Power Control cypress.com/go/powerpsoc cypress.com/go/plc Memory cypress.com/go/memory PSoC cypress.com/go/psoc Technical Support Touch Sensing cypress.com/go/touch cypress.com/go/support USB Controllers cypress.com/go/usb Wireless/RF cypress.com/go/wireless psoc.cypress.com/solutions PSoC 1 | PSoC 3 | PSoC 4 | PSoC 5LP Cypress Developer Community Community | Forums | Blogs | Video | Training PSoC is a registered trademark of Cypress Semiconductor Corp. All other trademarks or registered trademarks referenced herein are the property of their respective owners. Cypress Semiconductor 198 Champion Court San Jose, CA 95134-1709 Phone Fax Website : 408-943-2600 : 408-943-4730 : www.cypress.com © Cypress Semiconductor Corporation, 2009-2013. The information contained herein is subject to change without notice. Cypress Semiconductor Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any license under patent or other rights. Cypress products are not warranted nor intended to be used for medical, life support, life saving, critical control or safety applications, unless pursuant to an express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges. This Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by and subject to worldwide patent protection (United States and foreign), United States copyright laws and international treaty provisions. Cypress hereby grants to licensee a personal, non-exclusive, non-transferable license to copy, use, modify, create derivative works of, and compile the Cypress Source Code and derivative works for the sole purpose of creating custom software and or firmware in support of licensee product to be used only in conjunction with a Cypress integrated circuit as specified in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source Code except as specified above is prohibited without the express written permission of Cypress. Disclaimer: CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cypress reserves the right to make changes without further notice to the materials described herein. Cypress does not assume any liability arising out of the application or use of any product or circuit described herein. Cypress does not authorize its products for use as critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress’ product in a life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges. Use may be limited by and subject to the applicable Cypress software license agreement. www.cypress.com Document No.001-52701 Rev. *I 24