Salient features of the MCAN module are as follows:

• Conforms with CAN Protocol (ISO 11898-1:2015)
• Full CAN FD support (up to 64 data bytes)
• Up to 32 dedicated transmit buffers
• Configurable transmit FIFO, up to 32 elements
• Configurable transmit queue, up to 32 elements
• Configurable transmit Event FIFO, up to 32 elements
• Up to 64 dedicated receive buffers
• Two configurable receive FIFOs, up to 64 elements each
• Up to 128 filter elements
• Loop-back mode for self-test
• ECC check for Message RAM
• Clock stop and wakeup support
• Timestamp counter

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:

• For TMS320F2838xD and TMS320F2838xS devices, there may be two versions of some examples, a version that runs on CPU1 (28x) and another that runs on CM (M4). For example, in C2000ware version 3.04, CPU1 examples reside in C:\ti\c2000\C2000Ware_3_04_00_00\driverlib\f2838x\examples\c28x\mcan and the CM examples reside in C:\ti\c2000\C2000Ware_3_04_00_00\driverlib\f2838x\examples\cm\mcan. The projects have the same name, so they cannot exist together in the same CCS workspace. Before running any code on the M4 processor, the file cm_common_config_c28x.c should first be executed.
• For the examples to run successfully, it is very important to ensure the clock settings are correct. This is based on the input clock to the device. For details, see below note in the device.c file.

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

Figure 2-1 Adding the Predefined Symbol in Project Properties

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.

• GPIO configuration: Considering the MCAN signals can be routed to multiple pins, it is important to ensure the correct options are chosen based on your board design. By default, GPIO30 and GPIO31 are chosen for the MCAN function. The following settings are in the device.h file :

#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

• It is possible to communicate between MCAN and eCAN or DCAN, if FDF and BRS bits are disabled. In this case, only classic CAN frames can be used.

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-1 Output From MCANTX Pin for mcan_ex1_loopback.c

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.

Figure 3-2 Output of Bus-Monitoring Tool for mcan_ex1_loopback.c

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.

Figure 3-3 Output of Bus-Monitoring Tool for mcan_ex3_transmit.c

Figure 3-4 Output From MCANTX Pin for mcan_ex3_transmit.c

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.

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 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 and provides useful debug tips.

• Is clock to the MCAN module enabled? Check for this if writes to MCAN 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.
• When attempting to initiate communication on the bus for the very first time, ensure that 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.