TMS320F28377D： About CAN analyzer and 28377D communication

Hi Yeunming,

If you are using the sample code can_loopback, the RX pin is disconnected from CAN module so it cannot receive messages externally.  It can only receive messages from the module's TX pin.  Refer to the figure below:

Best regards,

Joseph

Thanks for your answer！

As you said, I have noticed this problem. I deleted the CAN test mode in the code, but I still can't implement the receiving function. I don't know where there are still problems. I hope your answer.

Regarding this problem, the official routine code I am modifying is given below, please help me to see if there is a problem：

int

main(void)

{

    InitSysCtrl();

    //对应28377D引脚

    InitGpio();


    GPIO_SetupPinMux(13, GPIO_MUX_CPU1, 2); //GPIO13 - CANRXB

    GPIO_SetupPinMux(12, GPIO_MUX_CPU1, 2);  //GPIO12 - CANTXB

    GPIO_SetupPinOptions(13, GPIO_INPUT, GPIO_ASYNC);

    GPIO_SetupPinOptions(12, GPIO_OUTPUT, GPIO_PUSHPULL);


    CANInit(CANB_BASE);

    CANClkSourceSelect(CANB_BASE, 0);

    CANBitRateSet(CANB_BASE, 200000000, 250000);


    DINT;


    InitPieCtrl();


    IER = 0x0000;

    IFR = 0x0000;


    InitPieVectTable();  

//    HWREG(CANB_BASE + CAN_O_CTL) |= CAN_CTL_TEST;

//    HWREG(CANB_BASE + CAN_O_TEST) = CAN_TEST_EXL;

//    HWREG(CANB_BASE + CAN_O_TEST) = CAN_TEST_RX;

    CANEnable(CANB_BASE);

    *(unsigned long *)ucTXMsgData = 8;

    sTXCANMessage.ui32MsgID = 5;                 

    sTXCANMessage.ui32MsgIDMask = 0;              

    sTXCANMessage.ui32Flags = MSG_OBJ_TX_INT_ENABLE; 

    sTXCANMessage.ui32MsgLen = sizeof(ucTXMsgData); 

    sTXCANMessage.pucMsgData = ucTXMsgData;         


    *(unsigned long *)ucRXMsgData = 8;

    sRXCANMessage.ui32MsgID = 5;                 

    sRXCANMessage.ui32MsgIDMask = 0;                

    sRXCANMessage.ui32Flags = MSG_OBJ_NO_FLAGS;

    sRXCANMessage.ui32MsgLen = sizeof(ucRXMsgData); 

    sRXCANMessage.pucMsgData = ucRXMsgData;        

    CANMessageSet(CANB_BASE, 2, &sRXCANMessage, MSG_OBJ_TYPE_RX);


    for(;;)

    {

        CANMessageSet(CANB_BASE, 1, &sTXCANMessage, MSG_OBJ_TYPE_TX);

        DELAY_US(1000*1000);

        CANMessageGet(CANB_BASE, 2, &sRXCANMessage, true);

       if((*(unsigned long *)ucTXMsgData) != (*(unsigned long *)ucRXMsgData)) 

        {

            //asm(" ESTOP0")

        }

        g_ulMsgCount++;

        (*(unsigned long *)ucTXMsgData)++;

    }

}

Hi Yeunming,

The CANB GPIO assignments look correct.  One thing you can try to troubleshoot this is to connect a scope probe to GPIO13, or the CANRX pin from the transceiver.  There should be some IO activity in that pin when there is a CAN frame that is ready for receiving in the CAN bus.  Is this something you can try out from your side?

Thanks,

Joseph

Ok, I will try to observe the GPIO pin activity with an oscilloscope,

thank you for your suggestions,

I will reply to you later

Hi Joawph,

According to your suggestion, I made a comparison measurement of two channels through an oscilloscope: first, connect the oscilloscope probe to the CAN_RX pin between the CAN transceiver and the DSP, and the other probe to the CAN analyzer and transceiver Between the CANH pins. After comparing the waveform of a data frame, it is found that the ACK on the CAN_RX pin does not show a dominant level, but the ACK on the CANH pin shows a dominant level, which means that the DSP does not receive the ACK sent by the CAN analyzer .

Thanks,

Yueming

Hi Yuenming,

Ok, ACK should be recessive in the transmitting node (in your case from the CAN analyzer) but should be driven low  (dominant) in the receiving side if it received a valid CAN frame.  How about the other bit fields other than ACK, do you see them in the CANRX side of the 28377D?

Thanks,

Joseph

Since it is the 28377D sending data to the CAN analyzer, the data that I probe the CANRX pin through the oscilloscope probe is the data sent by CANTX, and the other bit fields remain unchanged.

Hi Joseph，

Since the node will also monitor the message sent by itself while sending the message, so I use the oscilloscope to observe the data of the CANRX pin is actually the data sent by CANTX, and the ACK bit has not changed.

Hi Yuenming,

One other question.  Before doing any modification to the can_loopback test (except the CAN GPIO configuration) and running it as it is, did the test work?  Just trying to isolate if the problem is caused by an open connection to GPIO13.  In your set up, is it possible for you to use the other CANB GPIO mux options to narrow this down to an open GPIO connection?

Thanks,

Joseph

Hi Joseph,

If I add the test mode that I deleted earlier, and only modify GPIO, CAN can send and receive normally. Since my board is a self-made board, other GPIO ports have all been used. The hardware circuit does not support the multiplexing function of other GPIO ports. Therefore, only the GPIO13 of the CANB module can be used. The model of the CAN isolated transceiver I use here is ISO1050

Hi Yuenming,

Ok, thanks for providing the additional information.  On CAN transceiver ISO1050, can you verify VCC1 level?  Is it at 3.3V?  VCC1 I think is the digital supply and this determines the voltage level feeding into CANRX side of F28377D.  It should be at 3.3V level.  Other than this, one possibility why CAN does not see the data on GPIO13 is there might be an open connection.  To isolate if this is the issue, one suggestion is to configure GPIO13 as a digital output pin and drive a logic 0 and 1 data from F28377D (but you may have to disconnect CANRX from ISO1050) and see if you can observe the correct levels in GPIO13.  Is this something you can try?

Thanks,

Joseph

Hi Joseph,

Ok, I will try to do it according to your suggestions. I have measured the VCC1 level of ISO1050, and it is indeed about 3.3V. I think there is no problem with this chip. In addition, I have a question, is it because the can_loopback official example of controlsuite can only be used to test the internal loopback mode of the CAN core, and cannot be used in the normal transceiver mode (even if I delete the code of the test mode). Could it be because of a problem with the program that it cannot communicate normally?looking forward to your reply.

Thanks,

Yueming

Hi Yueming,

Ok, thanks for verifying the levels so you can eliminate that as a cause.  The can loopback example bypasses the data passing through CANRX.  In loopback mode, the CAN frames go out to CANTX (for observability) and are internally routed directly to the RX input.  By deleting the code for test mode, CAN should be able to receive the data from CANRX.  I think what your changes to the loopback example should be fine.

Regards,

Joseph

Hi Joseph，

I have conducted a general-purpose IO input and output test for the GPIO13 pin of 28377D. The test result is that GPIO13 and 28377D are connected without problems. Then in the TI Chinese community forum, a TI engineer told me that the can_loopback routine of controlsuite is only used to test the loopback mode of the CAN core (even if you comment out the test mode code), which is not applicable to the general transceiver mode. The engineer suggested me Use the can_ex5_simple_receive routine to configure the receive message object, but I have not tried it.

Hi Yueming,

Ok, let me know how that example works in your setup.

Regards,

Joseph

Hi Joseph，

After the hardware investigation, I have found the reason why I can't communicate. That is, I connected the communication pin CANH incorrectly. After correction, I have been able to communicate normally. Thank you for your patience and suggestions. It has helped me a lot.

Thanks，

Yueming