SPRACU9 October 2021 F29H850TU , F29H859TU-Q1 , TMS320F2800152-Q1 , TMS320F2800153-Q1 , TMS320F2800154-Q1 , TMS320F2800155 , TMS320F2800155-Q1 , TMS320F2800156-Q1 , TMS320F2800157 , TMS320F2800157-Q1 , TMS320F280033 , TMS320F280034 , TMS320F280034-Q1 , TMS320F280036-Q1 , TMS320F280036C-Q1 , TMS320F280037 , TMS320F280037-Q1 , TMS320F280037C , TMS320F280037C-Q1 , TMS320F280038-Q1 , TMS320F280038C-Q1 , TMS320F280039 , TMS320F280039-Q1 , TMS320F280039C , TMS320F280039C-Q1 , TMS320F28384D , TMS320F28384D-Q1 , TMS320F28384S , TMS320F28384S-Q1 , TMS320F28386D , TMS320F28386D-Q1 , TMS320F28386S , TMS320F28386S-Q1 , TMS320F28388D , TMS320F28388S , TMS320F28P550SG , TMS320F28P550SJ , TMS320F28P559SJ-Q1 , TMS320F28P650DH , TMS320F28P650DK , TMS320F28P650SH , TMS320F28P650SK , TMS320F28P659DH-Q1 , TMS320F28P659DK-Q1 , TMS320F28P659SH-Q1
C2000 and Code Composer Studio are trademarks of Texas Instruments.
All trademarks are the property of their respective owners.
CAN is a serial protocol that was originally developed for automotive applications. Due to its robustness and reliability, it now finds application in diverse areas such as industrial equipment, medical electronics, trains, aircraft, and so forth. CAN protocol features sophisticated error detection and confinement mechanisms and lends itself to simple wiring at the physical level. The original CAN protocol standard is now referred to as "classical" CAN to distinguish it from the more recent CAN FD standard. Figure 1-1 shows the typical wiring for CAN bus.
CAN Flexible Data Rate (CAN FD) is an enhancement to the classical CAN in terms of higher bit rates and the number of bytes transferred in one frame, thus increasing the effective throughput of communication. While classical CAN supports bit rates up to 1 Mbps and a payload size of 8 bytes per frame, CAN FD supports bit-rates up to 5 Mbps and a payload size of up to 64 bytes per frame. Figure 1-2 shows the frame structure for CAN FD frames.
Salient features of the MCAN module are as follows:
On devices like TMS320F2838xD and TMS320F2838xS, the MCAN module may be controlled either by CPU1 (28x) or the Connectivity Manager ( M4). This is not applicable for devices with only a 28x CPU. Below are some useful tips for a successful run of the examples:
"By default, the Device_init function assumes 25 MHz XTAL. If a 20 MHz crystal is used, add a predefined symbol "USE_20MHZ_XTAL" in your CCS project. If a different XTAL is used, please update the DEVICE_SETCLOCK_CFG macro accordingly. For example, if you are running the examples on a board with a 20 MHz input clock to the MCU, make sure USE_20MHZ_XTAL is added to the predefined symbols". For details, see Figure 2-1.
If you convert a RAM-based example to a Flash based example, it is important to once again add the USE_20MHZ_XTAL symbol for the flash-based project as well.
#define DEVICE_GPIO_CFG_MCANRXA GPIO_30_MCAN_RX // "pinConfig" for MCAN RX
#define DEVICE_GPIO_CFG_MCANTXA GPIO_31_MCAN_TX // "pinConfig" for MCAN TX
GPIO_30_MCAN_RX & GPIO_31_MCAN_TX are defined in pin_map.h
mcan_ex1_loopback.c – This example illustrates the loopback functionality of the MCAN module. The loopback operation is completely internal to the module. However, the transmitted data is visible in the MCANTX pin. An advantage of this testcase is that it does not need the transceiver, so it can run on boards like the controlCARD. To facilitate easy capturing of data on an oscilloscope, only four bytes of data are transmitted. However, it is transmitted as a CAN FD frame with Bit-rate switching. For more information, see Figure 3-1.
Figure 3-2 shows the output of the CAN bus monitoring tool. Note that both FDF and BRS bits are flagged in the output. The program terminates after transmitting four bytes.
mcan_ex3_transmit.c - This example demonstrates the MCAN External Transmit function. External communication is done between two CAN nodes. The receiving node could be another MCU or a CAN bus analysis tool capable of Receiving/ACKnowledging the transmitted frames. Both CAN nodes should connected through a CAN Transceiver. Nominal Bit Rate of 500 kbps and Data bit rate of 1 Mbps is used.
Standard Identifier (STD ID) 0x4 is transmitted with 64 data bytes one time. #defines that are not required for this test case have been commented out. However, they have been left in the code should the scope of this code be expanded to include Receive and FIFO functions.
mcan_ex4_receive.c - This example demonstrates the MCAN receive function. The transmitting node could be another MCU or a CAN bus analysis tool capable of transmitting CAN FD frames. Nominal Bit Rate of 500 kbps & Data bit rate of 1 Mbps is used. Only frames with a standard message ID of 0x4 is received. If another C2000 MCU with MCAN module is used as the transmitter, mcan_ex3_transmit.c can be run on it for the transmit function.
mcan_ex5_mask_filter_receive.c - This example demonstrates Reception (with mask filter) into RX-FIFO1. The transmitting node could be a CAN FD capable controller or a CAN bus analysis tool capable of transmitting CAN FD frames. Bits 0, 1 & 3 of the identifier are masked. So, these bits can have any value. This is achieved by using stdFiltelem.sfid1 = 00000001111b and stdFiltelem.sfid2 = 11111110100b (0 for “don’t care” ), which means any frame with an ID of 0000000x1xxb are received and stored into the FIFO. That is, frames with the following standard IDs are received: 0x004, 0x005, 0x006, 0x007, 0x00C, 0x00D, 0x00E, 0x00F. All other IDs are not received. Classic bit-mask filter is employed. This example may be used in conjunction with mcan_ex3_transmit. Nominal Bit Rate of 500 kbps and Data bit rate of 1 Mbps is used.
mcan_ex7_classic_transmit.c - This simple example demonstrates how to transmit classic CAN frames from the MCAN module. This example is very useful when the other node is only capable of processing classic CAN frames. This example is useful to ascertain the external communication capability of the MCAN node. Bit Rate configured is 500 kbps. A frame with an extended identifier of 0x15A5A5A5 is transmitted with 8 data bytes.
mcan_ex8_range_filter.c - This example demonstrates Reception (with range filter) into RX-FIFO1. The transmitting node could be a CAN FD capable controller or a CAN bus analysis tool capable of transmitting CAN FD frames. Only frames with extended IDs from 0x1FFFFF23 to 0x1FFFFF46 are received. Other IDs are not received. RXFIFO1 starts at an offset of 748 (2EC). MCAN Message RAM starts at 0x58000, so received messages will be copied starting at address 0x582EC. Note that as long as the respective ID bits match, "classic" CAN frames will also be received. Nominal Bit Rate of 500 kbps and Data bit rate of 1 Mbps is used.
This section illustrates some of the common mistakes and oversights while implementing a CAN bus. This is followed by some debugging tips useful to troubleshoot bus issues.
Unless working in the self-test mode, a minimum of two nodes are needed on the CAN bus for the following reason: When a node transmits a frame on the CAN bus, it expects an acknowledgment (ACK) from at least one other node on the network. Any time a CAN node successfully receives a message it will automatically transmit an ACK, unless that feature has been turned off ("silent mode", where a node receives the frame, but does not provide an ACK; the bus monitoring mode in MCAN). The node that provides the ACK does not need to be the intended recipient of the frame, although it could very well be. (All active nodes on the bus will provide an ACK, regardless of whether they are the intended recipients of that frame or not).
When the transmitting node does not receive an ACK, it results in an ACK error and the transmitting node keeps re-transmitting the frame forever. The Transmit Error Counter (TEC) will increment to 128 and stop there. REC stays at 0. Node will not go bus-off. No interrupts will be generated either. If another node is brought into the network, the TEC will start decrementing (all the way to 0) with every successful transmit.
One cannot directly connect MCANTX of node-A to MCANRX of node-B and vice versa and expect successful CAN communication. In this case, CAN is unlike other serial interfaces like SCI or SPI. For example, SCI can be made to work with a RS232 transceiver or through a direct connection (SCITX of one node to SCIRX of another node and vice versa). However, CAN bus needs a CAN transceiver for the following reason: In addition to converting the single-ended CAN signal for differential transmission, the transceiver also loops back the CANTX pin to the CANRX pin of a node. This is because a CAN node needs to be able to monitor its own transmission. Why?
This section highlights some common mistakes and provides useful debug tips.
While single-stepping through the test cases, if the code calls a function in a Driverlib file, CCS may display an error message as shown in Figure 6-1.
If this happens, click on “Locate File” and point to the Driverlib directory. For example, C:\Users\ Your_name\your_workspace\mcan_ex1_loopback\ device\driverlib.
TI PROVIDES TECHNICAL AND RELIABILITY DATA (INCLUDING DATASHEETS), DESIGN RESOURCES (INCLUDING REFERENCE DESIGNS), APPLICATION OR OTHER DESIGN ADVICE, WEB TOOLS, SAFETY INFORMATION, AND OTHER RESOURCES “AS IS” AND WITH ALL FAULTS, AND DISCLAIMS ALL WARRANTIES, EXPRESS AND IMPLIED, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT OF THIRD PARTY INTELLECTUAL PROPERTY RIGHTS. |
These resources are intended for skilled developers designing with TI products. You are solely responsible for (1) selecting the appropriate TI products for your application, (2) designing, validating and testing your application, and (3) ensuring your application meets applicable standards, and any other safety, security, or other requirements. These resources are subject to change without notice. TI grants you permission to use these resources only for development of an application that uses the TI products described in the resource. Other reproduction and display of these resources is prohibited. No license is granted to any other TI intellectual property right or to any third party intellectual property right. TI disclaims responsibility for, and you will fully indemnify TI and its representatives against, any claims, damages, costs, losses, and liabilities arising out of your use of these resources. |
TI’s products are provided subject to TI’s Terms of Sale (www.ti.com/legal/termsofsale.html) or other applicable terms available either on ti.com or provided in conjunction with such TI products. TI’s provision of these resources does not expand or otherwise alter TI’s applicable warranties or warranty disclaimers for TI products. |
Mailing Address: Texas Instruments, Post Office Box 655303, Dallas, Texas 75265
Copyright © 2021, Texas Instruments Incorporated |