LAUNCHXL-F28379D: Mixed eCAN-DCAN three nodes CANbus communication

Thank you for your response

Thank you for your response.

What our system needed is a continuously repeated data frame transmission appear on the CAN bus with this sequence:
1 - 2 - 3 - 1 - 2 -3 - 1 - 2 - 3 - (and so forth)
1: eCAN device
2: eCAN device
3: DCAN device

Our code looks like this

while(1)
{
    // Poll RxOk bit in CAN_ES register to check completion of Reception
    if(((HWREGH(CANB_BASE + CAN_O_ES) & CAN_ES_RXOK)) == CAN_ES_RXOK)
    {
        // Get the received message
        CAN_readMessage(CANB_BASE, RX_MSG_OBJ_ID1, rxMsgData1);
        CAN_readMessage(CANB_BASE, RX_MSG_OBJ_ID2, rxMsgData2);
        // CAN_readMessage(CANB_BASE, RX_MSG_OBJ_ID3, rxMsgData3);
        // RxReady=1;
        rxMsgCount++;
        //transmit upon receiving
        CAN_sendMessage(CANB_BASE, TX_MSG_OBJ_ID, MSG_DATA_LENGTH_TX, txMsgData);
    }
}

The code works well with 1 eCAN - 1 DCAN with sequence:

1 - 3 - 1 -3 - 1 - 3 - (and so forth)

Any thoughts or comment would be helpful. Thank you!

Thank you for your response!

I tried using a code as follows

if (CanbRegs.CAN_NDAT_X.bit.NewDatReg2>0)
    {
        rxMsgCount++;
    }

But it appears that the code didn't work.

Any comment or suggestion? Thank you.

In the figure above, I have succeeded in creating a continuous data frame transmission one after another, using 1 eCAN (launchxl-f28035) & 1 DCAN (launchxl-f28379d).

However, when the third device's (launchxl-f28069m: power off) CAN pin terminal is connected physically to the CAN bus, the DCAN device stop transmitting and register errors appear as follows:

F28379D: Boff 1, EWarn 1, EPass 1

F28069M: SE 1, CRCE 1

F28035: SE 1

Could any TI CAN expert suggest kindly why such errors could happen?

Thank you!

Thank you for your valuable comment!

I came back here, after I followed your valuable suggestion on using remote frame based on example can_ex_9_remote_frame fromSPRA876.
However, I found issue when using 1xLaunchXLf28069m and 2xLaunchXLf28379D. From three 120-ohm resistors on the bus, one is removed (desoldered), hence two 120-ohm resistors terminate the ends. The f28069m acts as master which is able to transmit two different remote frame on the bus (but only one at a time, using selector scheme) which is then received by two DCAN devices each has unique Message Object ID. The remote frame has been transmitted successfully, the reply message has also been received in the master (eCAN) mailbox. The issue is that once the remote frame is transmitted by master, only the Message Object ID with the lower value (hence higher priority) is able to respond. How to get the lower priority Message Object also be able to respond to the remote frame? Which DCAN register require attention to solve this issue? Please kindly advise. Thank you!

Thank you for your reply! The MSGIDs and their selected setups are provided below.

//Node 1 launchxlf28069
ECanaMboxes.MBOX3.MSGCTRL.bit.RTR = 1; //remote-transmission-request bit
ECanaMboxes.MBOX4.MSGCTRL.bit.RTR = 1; //remote-transmission-request bit
ECanaMboxes.MBOX3.MSGCTRL.bit.DLC = 8; 
ECanaMboxes.MBOX4.MSGCTRL.bit.DLC = 8; 
ECanaShadow.CANMD.bit.MD3 = 1; //configured as receive mailbox //corresponding remote reply data frame is received
ECanaShadow.CANMD.bit.MD4 = 1; //in the same mailbox
ECanaRegs.CANMD.all = ECanaShadow.CANMD.all;
eCANaMboxes.MBOX3.MSGID.bit.STDMSGID = 50;
eCANaMboxes.MBOX4.MSGID.bit.STDMSGID = 60;

//Node 2 launchxlf28379d
#define MSG_DATA_LENGTH 8
#define TX_MSG_OBJ_ID 1
CAN_setupMessageObject(CANB_BASE, TX_MSG_OBJ_ID, 50,
CAN_MSG_FRAME_STD, CAN_MSG_OBJ_TYPE_RXTX_REMOTE, 0,
CAN_MSG_OBJ_NO_FLAGS, 8);

//Node 3 launchxlf28379d
#define MSG_DATA_LENGTH 8
#define TX_MSG_OBJ_ID 1
CAN_setupMessageObject(CANB_BASE, TX_MSG_OBJ_ID, 60,
CAN_MSG_FRAME_STD, CAN_MSG_OBJ_TYPE_RXTX_REMOTE, 0,
CAN_MSG_OBJ_NO_FLAGS, 8);

The sequence of transmission is indicated by the code below.

//The selector scheme:
if(remote_frame_select == 1)
{
EALLOW;

ECanaShadow.CANME.all = ECanaRegs.CANME.all;
ECanaShadow.CANME.bit.ME3=0; //Disable
ECanaShadow.CANME.bit.ME4=0; //Disable
ECanaRegs.CANME.all = ECanaShadow.CANME.all;

ECanaMboxes.MBOX3.MSGCTRL.bit.RTR = 1;
ECanaMboxes.MBOX4.MSGCTRL.bit.RTR = 0;

ECanaShadow.CANME.all = ECanaRegs.CANME.all;
ECanaShadow.CANME.bit.ME3=1;
ECanaRegs.CANME.all = ECanaShadow.CANME.all;

ECanaShadow.CANTRS.all=0;
ECanaShadow.CANTRS.bit.TRS3=1;
ECanaRegs.CANTRS.all = ECanaShadow.CANTRS.all;

}

if(remote_frame_select == 2)
{
EALLOW;

ECanaShadow.CANME.all = ECanaRegs.CANME.all;
ECanaShadow.CANME.bit.ME3=0; //Disable
ECanaShadow.CANME.bit.ME4=0; //Disable
ECanaRegs.CANME.all = ECanaShadow.CANME.all;

ECanaMboxes.MBOX3.MSGCTRL.bit.RTR = 0;
ECanaMboxes.MBOX4.MSGCTRL.bit.RTR = 1;

ECanaShadow.CANME.all = ECanaRegs.CANME.all;
ECanaShadow.CANME.bit.ME4=1;
ECanaRegs.CANME.all = ECanaShadow.CANME.all;

ECanaShadow.CANTRS.all=0;
ECanaShadow.CANTRS.bit.TRS4=1;
ECanaRegs.CANTRS.all = ECanaShadow.CANTRS.all;

}

which is run at Node 1 (LaunchXL-F28069M).

After some assessments, I found this following particular line of code (provided from the example)

while(((HWREGH(CANB_BASE + CAN_O_ES) & CAN_ES_TXOK)) != CAN_ES_TXOK){}

freezes the DSP with the lower priority MSGID (in this case MSGID=60, the 3rd node).

This led to another question, what are the possible conditions that freeze the DSP? Thank you!

Hi Vince,

Thanks for your support. I found that using a CANTalker device, when sending the remote frame for Node 3, the remote frame for Node 2 is somehow also transmitted. This eventually causes Node 2 to respond since it is assigned with a higher priority MSGID.

1. Please swap the message IDs of Node 2 and Node 3. Let me know if the issue now moves to Node 2 (since before it was on Node 3).

I swapped the message IDS of Node 2 and Node 3, and, yes, the issue now moves to Node 2!

2. Please take a scope capture of the RX pin of the bad node during the full sequence of transmissions from the master.

Rather than a scope capture, I provided a data window captured by a Can analyzer, which shows that during request of the lower priority MSGID, the request of higher priority MSGID is somehow also carried and transmitted.

This led to another question, is this more a register programming issue, or does the CAN protocol behave this way?

Hi Hareesh & Vince,

Thank you very much for your helpful suggestions.

1) Removing the unnecessary resistors on the CanBus solved the physical layer issue.

2) Understanding the differences of eCAN (Bitfields) and DCAN (Driverlib), TI examples, and also how to modifiy DCAN registers helped in writing the code.

3) Inserting a very long delay really helps understanding the mechanism and debugging the issues.

The three nodes communication are working fine using data frames broadcast. It's not perfect, but it is working.

Thank you for your support!

Nur