CCS: CAN driver for ti-rtos

I recommend that you put all the functions that access the CAN module into one task and one interrupt service routine. Use TI-RTOS mailboxes (not to be confused with CAN mailboxes or messages) to request data transmission and reception from the CAN task and the CAN interrupt routine. 

The version of the driver library file can.c in TivaWare version 2.2.0.295 and earlier, and the ROM based version, use interface one (IF1) registers for most functions and interface two (IF2) registers for receiving messages (CANMessageGet()). This can create an issue when the CAN functions are used in the main application code
and in interrupt routines or in multiple threads of an RTOS. The consistency of the interface registers is not maintained during the interrupt or task switch. An updated version of can.c which I attached uses IF1 registers for all functions when the CPU is not in an exception and uses IF2 registers when the CPU is in an exception state. This simplifies writing code for CAN using interrupts. When using an RTOS, all CAN functions should be in one thread or in one interrupt routine. The can.c file located in the driverlib folder of the latest TivaWare installation can be replaced with the provided can.c file and the driver library rebuilt, or the provided can.c file can be added directly to your project.

 /cfs-file/__key/communityserver-discussions-components-files/81/can.c

I wish I had a simple example for you, but I don't. There are so many variations on how to implement the RTOS CAN tasks and mailboxes. I can describe a simple example.

Assume we have three tasks that need CAN communication. The first task (CANTX1) periodically will transmit a 4 byte message always to the same ID. The second task (CANRX2) only receives data from a CAN message, but the message can be from any of multiple ID's generated by a know fixed filter. The third task (CANTXRX3) will send a CAN message and expect a response. The ID for the message sent and the ID of the expected response change. We have a fourth task that does the CAN interfacing and a CAN interrupt routine.

Statically allocate the mailboxes. You need a simple 4 byte mailbox for task CANTX1 (Mailbox1). It will contain the 4 bytes that need to be transmitted. The ID can be hardcoded. You need 12 bytes for the mailbox for task CANRX2 (Mailbox2). Three bytes for the received ID, one byte for the length of data received and 8 bytes for the data. For the third task, we need three mailboxes. The first mailbox is for sending a CAN frame and needs up to 12 bytes, three for the ID, one for the length and eight for the data (Mailbox3). The second mailbox is for setting up the receive message and needs up to six bytes, three for the ID and three for the mask (Mailbox4). The third mailbox is used by the interrupt routine and needs up to eight bytes, three for the received ID, one for the length and eight for the data (Mailbox5).

The CAN task loops checking Mailbox1, Mailbox3 and Mailbox4. When it sees Mailbox1 pending, it reads the contents and sets up a CAN frame to transmit the predefined ID and the 4 bytes of data provided. When it sees Mailbox3 pending, it sets up a CAN transmit message using the ID, length and data from the mailbox. When it sees Mailbox4 pending, it sets up a CAN receive frame with the ID, and mask from the mailbox.

During initialization of the CAN module a receive message can be configured to receive frames for the CANRX2 task. The interrupt routine can then post to Mailbox2 the received ID, length and data. Also, when it sees received data in the message setup by Mailbox4, it can post the ID, length and data received in Mailbox5.

I hope this helps.