LAUNCHXL-F28P65X: CAN Communication Issue Between TMS320F28P650DK9 and ZC702 (Xilinx APSOC)

Hi Bala,

Can you confirm that JP9 is shorted/connected to ensure the termination resistance is inserted on the CAN Bus for that receiver node?

Can you please provide scope shots of the CAN_H/CAN_L signals while attempting to communicate between the two devices? This will help provide more insight into the failure and help us with next steps.

Best Regards,

Zackary Fleenor

Hi Fleenor,

Yes, JP9 is shorted.

Regarding the communication between the F28P65x and the ZC702, the CAN message sent from the F28P65x is successfully received by the ZC702. However, the reverse operation is not working—messages sent from the ZC702 are not being received by the F28P65x.

I have attached the scope shots below. Please review them and provide your insights.


1.while sending data from f28p65x to zc702 probed the signal on f28p65x
 




2.while sending data from zc702 to f28p65x probed the signal on  f28p65x

Hi Fleenor,

Now when i was tring to communicate between two f28p65x launch pad.I took the can_ex5_transmit_receive example and then flashed rx in one board and tx in another board in  debug mode when i tried to send data it is going in a infinite loop of the interupt function.(checked this using a print)

__interrupt void
canaISR(void)
{
uint32_t status;

//
// Read the CAN-B interrupt status to find the cause of the interrupt
//
status = CAN_getInterruptCause(CANA_BASE);

printf("CAN_getInterruptCause = %lu\n",status);

//
// If the cause is a controller status interrupt, then get the status
//
if(status == CAN_INT_INT0ID_STATUS)
{
//
// Read the controller status. This will return a field of status
// error bits that can indicate various errors. Error processing
// is not done in this example for simplicity. Refer to the
// API documentation for details about the error status bits.
// The act of reading this status will clear the interrupt.
//
status = CAN_getStatus(CANA_BASE);

//
// Check to see if an error occurred.
//
#ifdef TRANSMIT
if(((status & ~(CAN_STATUS_TXOK)) != CAN_STATUS_LEC_MSK) &&
((status & ~(CAN_STATUS_TXOK)) != CAN_STATUS_LEC_NONE))
#else
if(((status & ~(CAN_STATUS_RXOK)) != CAN_STATUS_LEC_MSK) &&
((status & ~(CAN_STATUS_RXOK)) != CAN_STATUS_LEC_NONE))
#endif
{
//
// Set a flag to indicate some errors may have occurred.
//
errorFlag = 1;  
}
}

Hardware connection : 

JP9 is shorted ,CAN_H to CAN_H , CAN_L to CAN_L ,GND to GND 


note : when i tried to print the the status variable i got 32768 (CAN_getInterruptCause = 32768 this print  is being printed continuosly)

please let me know what mistake i am doing here

Hello, I don't notice any obvious mistake from the code shared.

Similar to before, could you provide scopeshots of CAN_H/CAN_L and CAN_TX/CAN_RX signals during execution?

Can you explain how it enters an infinite loop in the interrupt function? Is it that the code stops running or begins looping within the ISR itself, or that the ISR is continually triggered and completes and repeats the entire ISR back to back?

Best Regards,

Zackary Fleenor

Hi Fleenor,
               Found out this issue was caused by a hardwere connection mistake ,once it was fixed the interrupts   where hitting correctly and issue is resolved .Now i have one more doubt i was trying to receive a can message without specifying the msgID by give it as 0 and mask value aswell 0 ,but unable receive the message .(note using the same can_ex5_transmit_receive example)

TX message object :

CAN_setupMessageObject(CANA_BASE, TX_MSG_OBJ_ID, 0x15555555,
CAN_MSG_FRAME_EXT, CAN_MSG_OBJ_TYPE_TX, 0,
CAN_MSG_OBJ_TX_INT_ENABLE, MSG_DATA_LENGTH);

RX message object :

CAN_setupMessageObject(CANA_BASE, RX_MSG_OBJ_ID, 0,
CAN_MSG_FRAME_EXT, CAN_MSG_OBJ_TYPE_RX, 0,
CAN_MSG_OBJ_RX_INT_ENABLE, MSG_DATA_LENGTH);

as you can see above this is how i am setting my tx ,rx message object .Please let me what mistake i am doing here 

Hey Bala,

Glad you were able to resolve the original issue. Can you provide any more details on the hardware connection mistake and the implemented fix?

Also, just to keep things organized and easily accessible, would you mind creating a new E2E thread for this msgID=0 issue you are experiencing?

We want to help to resolve the new issue, but don't want the information to get lost in a thread meant to address a different issue.

Thanks and Regards,

Zackary Fleenor

Hi Fleenor,

               Actually it was not a connection issue ,the issue was caused by faulty jumper used in the connection between the launch pads.I have created a new E2E thread for the msgID issue also .

Thanks and Regards,
Bala Nigesh