SPRACE5A May 2019 – May 2021 F29H850TU , F29H859TU-Q1 , TMS320F280021 , TMS320F280021-Q1 , TMS320F280023 , TMS320F280023-Q1 , TMS320F280023C , TMS320F280025 , TMS320F280025-Q1 , TMS320F280025C , TMS320F280025C-Q1 , TMS320F280040-Q1 , TMS320F280040C-Q1 , TMS320F280041 , TMS320F280041-Q1 , TMS320F280041C , TMS320F280041C-Q1 , TMS320F280045 , TMS320F280048-Q1 , TMS320F280048C-Q1 , TMS320F280049 , TMS320F280049-Q1 , TMS320F280049C , TMS320F280049C-Q1 , TMS320F28075 , TMS320F28075-Q1 , TMS320F28076 , TMS320F28374D , TMS320F28374S , TMS320F28375D , TMS320F28375S , TMS320F28375S-Q1 , TMS320F28376D , TMS320F28376S , TMS320F28377D , TMS320F28377D-EP , TMS320F28377D-Q1 , TMS320F28377S , TMS320F28377S-Q1 , TMS320F28378D , TMS320F28378S , TMS320F28379D , TMS320F28379D-Q1 , TMS320F28379S , TMS320F28384D , TMS320F28384S , TMS320F28386D , TMS320F28386S , TMS320F28388D , TMS320F28388S , TMS320F28P650DH , TMS320F28P650DK , TMS320F28P650SH , TMS320F28P650SK , TMS320F28P659DH-Q1 , TMS320F28P659DK-Q1 , TMS320F28P659SH-Q1
C2000 and Code Composer Studio are trademarks of Texas Instruments Incorporated.
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 applications in diverse areas such as Industrial equipment, appliances, medical electronics, trains, air crafts, and so forth. CAN protocol features sophisticated error detection (and isolation) mechanisms and lends itself to simple wiring at the physical level.
Figure 1-1 shows the typical implementation of the CAN bus.
This section provides a brief description of the example projects, along with applicable waveforms captured with an oscilloscope. Note that the examples are within C2000Ware.
This example illustrates the use of self-test mode. A message is transmitted once per second, using a simple delay loop for timing. The message that is sent is a 2 byte message that contains an incrementing pattern. This example sets up the CAN controller in "External" Loopback test mode. Data transmitted is visible on the CANTXA pin and is received internally back to the CAN Core. It is important that the GPIO mapping in device.h file in this project is edited to reflect the GPIO pins that are used for CAN function in your hardware. Otherwise, the transmitted data will not be seen on CANTXA pin.
Figure 2-1 shows the activity on the CANTXA pin.
Similar to can_ex1_loopback.c, but uses interrupts.
This example shows basic setup of CAN in order to transmit and receive messages. It sets up CAN-A as the transmitter and CAN-B as the receiver. A receive interrupt is asserted on CAN-B to verify the received data.
This example illustrates how to setup the CAN module for transmission. It could prove very useful to check the hardware connections of the CAN circuit.
Figure 2-2, Figure 2-3 and Figure 2-4 show how data is stored in the IFxDATA registers.
31 | 30 | 29 | 28 | 27 | 26 | 25 | 24 | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
Data_3 | Data_2 | Data_1 | Data_0 | ||||||||||||||||||||||||||||
R/W-0h | R/W-0h | R/W-0h | R/W-0h | ||||||||||||||||||||||||||||
31 | 30 | 29 | 28 | 27 | 26 | 25 | 24 | 23 | 22 | 21 | 20 | 19 | 18 | 17 | 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
Data_7 | Data_6 | Data_5 | Data_4 | ||||||||||||||||||||||||||||
R/W-0h | R/W-0h | R/W-0h | R/W-0h | ||||||||||||||||||||||||||||
With the above configurations, data is transmitted in the order shown in Figure 2-5.
Figure 2-5 depicts the waveform on the CANTXA pin.
Figure 2-6 shows the waveform at the CANRXA pin. Note that during the ACK phase, the transmitting node transmits a recessive, but it is driven low by the receiver.
This example is a simple illustration of how to setup the CAN module for reception. This example could prove very useful to generate an ACK for another CAN node.
This example demonstrates the ability of the CAN-A module to transmit a Remote-frame and receive a response in the same mailbox. CAN-B node is configured to respond to the Remote frame. If CAN-B is not available, a CAN bus analyzer may be used to provide a response. Note that the response time from such equipment may be more, because it involves some overhead due to the application running on the PC.
Figure 2-7 shows the response from a bus analyzer. Note that it takes about 13 ms for the response to show up on the bus.
Figure 2-8 shows the response from CAN-B. Response is in microseconds in this case.
Figure 2-9 demonstrates the ability of the module to respond to a Remote-frame. A remote frame is transmitted from the CAN bus analyzer and the module responds.
This example demonstrates acceptance mask filtering. It can be used to evaluate the effects of MXtd & MDir bits. Table 2-1 shows the various scenarios and the outcomes. Mailbox direction was set to Receive (Dir = 0) , An extended ID was written to the mailbox (Xtd = 1) and filtering enabled (UMask = 1). MXtd and MDir bits were cycled through the four possible combinations.
MXtd | Mdir | Outcome |
---|---|---|
1 | 1 | Frame received |
1 | 0 | Frame received |
0 | 1 | Frame received |
0 | 0 | Frame received |
MXtd | Mdir | Outcome |
---|---|---|
1 | 1 | Frame not received |
1 | 0 | Frame not received |
0 | 1 | Frame received |
0 | 0 | Frame received |
MXtd | Mdir | Outcome |
---|---|---|
1 | 1 | Frame not received |
1 | 0 | Frame not received |
0 | 1 | Frame received |
0 | 0 | Frame received |
It is important to remember that the stored Message Identifier will be over-written by the identifier of the received frame. In order for acceptance filtering to work correctly for subsequent frames, the message object must be reinitialized with the original identifier.
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 DCAN module has this feature). 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. In this situation, the TxRqst bit for the transmitting mailbox does not get set. 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 CANTX of node-A to CANRX 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 in the design and implementation of a CAN bus network.
This section provides some tips for GPIO reconfiguration, project cloning, migrating from eCAN and bit-timing configuration.
The example programs run under the Driverlib frame work. They were tested with the following GPIO configuration for the CAN pins (see Table 4-1).
CAN Function | GPIO |
---|---|
CANTXA | GPIO71 |
CANRXA | GPIO70 |
CANTXB | GPIO72 |
CANRXB | GPIO73 |
The C2000Ware examples, by default, have the following GPIO configuration for CAN operation:
#define DEVICE_GPIO_CFG_CANRXA GPIO_30_CANRXA // "pinConfig" for CANA RX
#define DEVICE_GPIO_CFG_CANTXA GPIO_31_CANTXA // "pinConfig" for CANA TX
#define DEVICE_GPIO_CFG_CANRXB GPIO_10_CANRXB // "pinConfig" for CANB RX
#define DEVICE_GPIO_CFG_CANTXB GPIO_8_CANTXB // "pinConfig" for CANB TX
This may have to be modified depending on which GPIO pins are used for CAN operation in your hardware. This is a very important step and, if applicable, must be done for every example project. Use the procedure discussed in Section 4.1.1 to change the GPIO configuration.
The example C file has the following statements:
GPIO_setPinConfig(DEVICE_GPIO_CFG_CANRXA);
GPIO_setPinConfig(DEVICE_GPIO_CFG_CANTXA);
GPIO_setPinConfig(DEVICE_GPIO_CFG_CANRXB);
GPIO_setPinConfig(DEVICE_GPIO_CFG_CANTXB);
#define DEVICE_GPIO_CFG_CANRXA GPIO_30_CANRXA // "pinConfig" for CANA RX
The constant #define GPIO_30_CANRXA 0x00081C01U is defined in pin_map.h file.
To change the GPIO mapping, edit the device.h file as follows: (Table 4-1 was used as an example).
// Modified configuration
#define DEVICE_GPIO_CFG_CANRXA GPIO_70_CANRXA // "pinConfig" for CANA RX
#define DEVICE_GPIO_CFG_CANTXA GPIO_71_CANTXA // "pinConfig" for CANA TX
#define DEVICE_GPIO_CFG_CANRXB GPIO_73_CANRXB // "pinConfig" for CANB RX
#define DEVICE_GPIO_CFG_CANTXB GPIO_72_CANTXB // "pinConfig" for CANB TX
device.h file is unique to every example directory in the workspace. The edits you make for one project will not get carried over across other projects.
For the ControlCARD, CANTXA is on GPIO31 and CANRXA is on GPIO30. CANTXB is on GPIO8 and CANRXB is on GPIO10. GPIOs will be different on Launchpad. For more information, see the board schematics in the /boards directory in C2000ware.
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 4-3.
If this happens, click on “Locate File” and point to the Driverlib directory. For example, C:\Users\ Your_name\workspace_v7\can_ex2_loopback_interrupts\ device\driverlib.
This section provides some helpful hints if you are migrating from the eCAN module to the DCAN module. DCAN follows a very different register structure compared to eCAN and hence code written for one module cannot be migrated to another. The following section highlights the differences, but also illustrates the functional similarities between the two modules.
The following features are available in DCAN that are not available in eCAN:
The following are the features that are available in eCAN that are not available in DCAN:
Table 4-2 shows the equivalent registers and bit-fields in eCAN and DCAN and also some functional differences.
Function | eCAN | DCAN | Comments |
---|---|---|---|
CAN module software reset bit | CANMC.SRES | CAN_CTL.SWR | |
Automatic bus-on (after bus-off) | CANMC.ABO | CAN_CTL.ABO | |
Self-test mode | CANMC.STM | CAN_CTL.Test | Further selection needed for DCAN in CAN_TEST register |
Configuration mode | CANMC.CCR | CAN_CTL.Init | |
Configuration mode enabled | CANES.CCE | CAN_CTL.CCE | |
Mailbox interrupt source | CANGIFx.MIVy | CAN_INT.INTnID | |
Interrupt line selection (for mailbox) | CANMIL | CAN_IP_MUX21 | |
Interrupt line selection (for error & status) | CANGIM.GIL | Hardwired to CANINT0 | |
CAN to PIE interrupt line0 enable | CANGIM.I0EN | CAN_CTL.IE0 | |
CAN to PIE interrupt line1 enable | CANGIM.I1EN | CAN_CTL.IE1 | |
Transmit Error Counter | CANTEC.TEC | CAN_ERRC.TEC | |
Receive Error Counter | CANREC.REC | CAN_ERRC.REC | |
Bus-off status | CANES.BO | CANES.Boff | |
Early warning (TEC or REC = 96) | CANES.EW | CANES.EWarn | |
Error passive | CANES.EP | CANES.EPass | |
Acceptance mask register | LAM | CAN_IFxMSK | |
Acceptance mask filter for a Mailbox | LAM.LAM | CAN_IFnMSK.Msk | Mask bit behavior is opposite |
Mailbox message-ID register | MSGID | CAN_IF1ARB | |
Mailbox enable or disable | CANME.MEn | CAN_IFnARB.MsgVal | In DCAN, MBX can remain "enabled" while configuring the MSGID. |
Extended Identifier | MSGID.IDE | CAN_IFxARB.Xtd | |
Mailbox direction | CANMD.MDn | CAN_IFxARB.Dir | |
Message ID | MSGID.ID | CAN_IFxARB.Id | |
Lost message indication | CANRML.RMLn | CAN_IFxMCTL.MsgLst | |
Transmission request | CANTRS.TRSn | CAN_IFxMCTL.TxRqst | |
# of bytes in a frame | MSGCTRL.DLC | CAN_IFxMCTL.DLC | |
Transmit or Receive priority | Higher numbered MBX has priority | Lower numbered MBX has priority | |
Enabling/disabling interrupts for a specific mailbox | CANMIM | IFnMCTL.TxIE or IFnMCTL.RxIE |
In this section, the usage of the various bit-fields in the CANBTR register is illustrated.
The formula for bit-rate is:
Where BRP is the value of (BRPreg + 1) and Bit-time = (TSEG1reg + 1) + (TSEG2reg + 1) + 1
In the above equations BRPreg , TESG1reg and TSEG2reg represent the actual values written in the corresponding fields in the CANBTR register. The parameters TSEG1reg, TSEG2reg, SJWreg, and BRPreg are automatically enhanced by 1 when the CAN module accesses these parameters. If the BRPE field is used, it should be concatenated with the BRP field.
Example 1
Assume the following parameters are desired with a CAN module clock of 200 MHz:
Bit-rate = 500 kbps, SJW = 4, TSEG1 = 9 & TSEG2 = 6.
This is achieved by writing a value of 0x000058D8 in the CANBTR register. Here, TSEG1reg = 8, TSEG2reg = 5, SJWreg = 3, and BRPreg = 24
Effective BRP value = (BRPreg + 1) = 25
Effective TSEG1 value = (TSEG1reg + 1) = 9
Effective TSEG2 value = (TSEG2reg + 1) = 6
Effective SJW value = (SJWreg + 1) = 4
Bit-time = (TSEG1reg + 1) + (TSEG2reg + 1) + 1 = 16
Plugging these numbers into the bit-rate equation:
Example 2
Assume the following parameters are desired with a CAN module clock of 200 MHz:
Bit-rate = 50 kbps, SJW = 4, TSEG1 = 9 & TSEG2 = 6.
This is achieved by writing a value of 0x000358F9 in the CANBTR register. Here, TSEG1reg = 8, TSEG2reg = 5, SJWreg = 3, BRPE = 11b , BRP = 111001b. Effective BRPreg = 11111001b (249). Note that BRPE field is concatenated with the BRP field.
Effective BRP value = (BRPreg + 1) = 250
Effective TSEG1 value = (TSEG1reg + 1) = 9
Effective TSEG2 value = (TSEG2reg + 1) = 6
Effective SJW value = (SJWreg + 1) = 4
Bit-time = (TSEG1reg + 1) + (TSEG2reg + 1) + 1 = 16
Plugging these numbers into the bit-rate equation:
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 © 2020, Texas Instruments Incorporated |