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.

Figure 1-1 Typical Implementation of a CAN Bus

• Full implementation of CAN protocol, version 2.0B
• 32 mailboxes, each with the following properties:
  • Configurable as receive or transmit
  • Configurable with standard or extended identifier
  • Has a programmable receive mask (every mailbox has its own mask)
  • Supports data and remote frame
  • Composed of 0 to 8 bytes of data
  • Employs a programmable interrupt scheme with two interrupt levels
• Automatic reply to a remote request message
• Automatic retransmission of a frame in case of loss of arbitration or error

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.

• can_ex1_loopback.c

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.

Figure 2-1 can_ex1_loopback

• can_ex2_loopback_interrupts.c

Similar to can_ex1_loopback.c, but uses interrupts.

• can_ex3_external_transmit.c

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.

• can_ex4_simple_transmit.c

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.

Figure 2-4 IFxDATA Registers in CCS Expressions Window

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-5 can_ex4_simple_transmit

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.

Figure 2-6 Waveform at the CANRXA Pin

• can_ex5_simple_receive.c

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.

• can_ex8_Remote_Tx.c

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-7 can_ex8_Remote_Tx-PEAK

Figure 2-8 shows the response from CAN-B. Response is in microseconds in this case.

Figure 2-8 can_ex8_Remote_Tx-28x

• can_ex9_Remote_Answer.c

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.

Figure 2-9 can_ex9_Remote_Answer

• can_ex10_Mask.c

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.

• An Ext ID frame, satisfying the filtering criterion, is transmitted. MXtd & Mdir bits have no bearing on the frame reception in all four cases.
  Table 2-1 Extended ID Frame (passing filter criterion)

  MXtd	Mdir	Outcome
  1	1	Frame received
  1	0	Frame received
  0	1	Frame received
  0	0	Frame received

• An STD ID frame, with exact match for the 11 applicable bits (bits 28:18), is transmitted. In the case where MXtd is 0, the Xtd bit of the mailbox was not used for filtering. Rather, the 11 applicable bits were found to be matching and, hence, the frame was received.
  Table 2-2 Standard ID Frame (exact match)

  MXtd	Mdir	Outcome
  1	1	Frame not received
  1	0	Frame not received
  0	1	Frame received
  0	0	Frame received

• An STD ID frame, with passing filter criterion for the 11 applicable bits (bits 28:18), is transmitted. In the case where MXtd is 0, the Xtd bit of the mailbox was not used for filtering. Rather, the 11 applicable bits were found to be matching and the hence the frame was received.
  Table 2-3 Standard ID Frame (passing filter criterion)

  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 has to do with the ACK requirement mandated by the CAN protocol. When a node transmits a frame on the CAN bus, it expects an ACK from at least one other node on the network. For the ACK phase, the transmitter puts out a 1 and expects to read back a 0.
• During arbitration, a node with a higher-priority MSGID needs to be able to override a 1 with a 0. Here again, the transmitter needs to be able to read back the transmitted data. When a node puts out a 1 and reads back a 0 during the arbitration phase, it loses arbitration.

This section highlights some common mistakes in the design and implementation of a CAN bus network.

• Is clock to the CAN module enabled? Check for this if writes to CAN registers are not going through. Clock is enabled through a bit in the PCLKCRn register.
• Comment all EDIS from your code until you get it to work. You could add it later. Many registers and bits are EALLOW protected and a write may not go through if EALLOW is not active.
• Try your code without interrupts first. Use polling instead. Once polling works, you can add interrupts later.
• If a specific mailbox is not working, have you attempted to use a different mailbox? Have the mailboxes been enabled and the mailbox direction correctly configured?
• When attempting to initiate communication on the bus for the very first time, ensure that the the mailbox in the transmitting node and the receiving node are programmed with the same MSGID. Do not use Acceptance Mask Filtering initially. Filtering could be added later once it is confirmed there are no hardware issues with the bus.

• Has the bus been terminated correctly (with 120-Ω) at either ends (only)? The bus must be terminated only at either ends and with a 120-Ω resistor. In other words, no more than two terminator resistors may be present on the bus, unless split termination is followed, in which case there will be two resistors on either ends. While designing a CAN bus system, it is important that the termination resistors can be enabled/disabled from outside the system enclosure. This scheme makes it easy when nodes have to be added/removed to/from the network.
• Are all CAN nodes configured for the same bit-rate? Mis-matched node bit rates would repeatedly introduce error frames on the bus. Capture the output of a node on the oscilloscope to physically verify the bit-time.
• Have you tried a lower bit-rate? Say, 50 kbps, for example? Timing issues concerning propagation delays may be caught trying a lower bit-rate. Ensure that CANBTR register has the programmed value.
• Have you tried to reduce the bus length and number of nodes?
• Before the occurrence of the error condition, were any error-frames seen on the bus? This could point to timing violations or noise issues.
• How many nodes are there in the bus? (In non-self-test mode, there must be at least two nodes on the network, due to the acknowledge (ACK) requirement mandated by the CAN protocol)

• To see the waveform until the ACK phase, a transceiver must be connected to the node. Without a transceiver, the node immediately goes into an error state.
• Check if the CAN frame is correctly seen at the CANRX pin of the MCU and it is of the expected bit-rate.
• If using an oscilloscope with a built-in CAN trigger, make sure that the signal configured for triggering matches the signal being probed on the board. Many oscilloscopes are capable of triggering on CAN-transmit (CANTX), CAN-receive (CANRX), CAN_H and CAN_L signals, in addition to Start-of_Frame (SOF), Remote frames, Error frames and specific MSGIDs.
• If the scope does not decode the waveform, make sure input threshold value for the channel is correct. This is similar to the “trigger level” that is normally used for signals.

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).

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);

• The function GPIO_setPinConfig(uint32_t pinConfig) is in gpio.c file.
• The argument DEVICE_GPIO_CFG_CANRXA is in device.h file.

#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

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.

1. All projects start their life as a .projectspec file. They exist in C:\ti\c2000\C2000Ware_1_00_05_00\driverlib\f2837xd\examples\cpu1\can\CCS directory. Note that the exact path would depend on the version of C2000ware installed in your computer.
   Figure 4-1 Directory Containing the .projectspec Files
2. Make a copy of an existing .projectspec file. For example, suppose you want to create a new project called can_ex4_simple_transmit. Start by making a copy of can_ex1_loopback.projectspec and rename it as can_ex4_simple_transmit.projectspec.
3. Open can_ex4_simple_transmit.projectspec and replace the two instances of can_ex1_loopback with can_ex4_simple_transmit, the name of the new testcase.
4. In the C:\ti\c2000\C2000Ware_1_00_05_00\driverlib\f2837xd\examples\cpu1\can directory, make a copy of the can_ex1_loopback.c file and rename it as can_ex4_simple_transmit.c. This is very important because when the .projectspec file is imported into Code Composer Studio™, it copies the new file into the target directory when it executes the following statement: <file action="copy" path="../can_ex4_simple_transmit.c" targetDirectory="" />.
5. Import the can_ex4_simple_transmit.projectspec file into CCS. Note that the project directories are created under C:\Users\Your_name\workspace_v8, not in: \ti\c2000\C2000Ware_1_00_05_00\driverlib\f2837xd\examples\cpu1\can.
   Figure 4-2 Project Directories in CCS Workspace