LPC54616 MCAN and Bus Off

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

LPC54616 MCAN and Bus Off

1,119 Views
jays
Contributor II

Hello,

I've been working on some MCAN code for the LPC54616 using the 2.5.0 SDK MCAN drivers. I have my code working in both internal and external loop back. When I take the code out of internal/external loop back and connect ports 0 and 1 together via a cable it doesn't work for me. There was old code that was used to verify the hardware using the old can.c/can.h drivers which worked (with the cable) but with the fsl_mcan drivers I get the bus off happening and the INIT bit set in the CCCR. I assume this is because of the error count in the ECR register.

In the code the clocking is set as:

/* attach 12 MHz clock to FLEXCOMM0 (debug console) */
CLOCK_AttachClk( BOARD_DEBUG_UART_CLK_ATTACH );:

BOARD_InitPins();

// MCU clock is 12 MHz, from schematics run at 96 MHz, MCAN example used 48 MHz
BOARD_BootClockFROHF96M();

/* Set MCAN clock 96/12=8MHz. */
CLOCK_SetClkDiv( kCLOCK_DivCan0Clk, 12U, true );
CLOCK_SetClkDiv( kCLOCK_DivCan1Clk, 12U, true );

MCAN_Init(
  pMcanObj->pMcanBase,
  &(pMcanObj->mcanConfig),
  CLOCK_GetFreq( kCLOCK_MCAN0 )
);

MCAN_Init(
  pMcanObj->pMcanBase,
  &(pMcanObj->mcanConfig),
  CLOCK_GetFreq( kCLOCK_MCAN1 )
);

I've attached a file with the MCAN registers showing the registers at various stages.

  • OPEN(0) is for port 0 and OPEN(1) is for port 1.
  • After the registers there is a TX of a single byte frame of 0x60.
  • Then some of the registers in the callback for port 1. These show the off line bit in the CCCR being set. There are other indications of errors in the IR and PSR registers too.
  • Then there is the registers for both ports before they are shut down. For port 1 (CLOSE(1)) the ECR port has the RX error count maxed out.

So would someone have any ideas of things to look at or knowledge of issues on getting MCAN to work?

Thank is advance.

Jay S.

0 Kudos
Reply
3 Replies

960 Views
jays
Contributor II

Figured out my problem.

Had a bad pin configuration for one of the CAN ports.

Thank you.

Jay

0 Kudos
Reply

960 Views
xiangjun_rong
NXP TechSupport
NXP TechSupport

Hi, Jay,

From your description, it appears that you connect the on-chip two CAN module together, for example CAN1_TD is connected to CAN0_RD, CAN1_RD to CAN0_TD, I do not think the connection is okay, because the CAN module also receives the frame when the same CAN module transmits data frame.

You have to use two CAN transceiver, for example CAN0_TD/CAN0_RD is connected to CAN0 transceiver, CA1_TD/CAN1_RD is connected to CAN1 transceiver, connect the two CAN transceiver by CAN_H/CAN_L together.

Pls have a try.

BR

Xiangjun rong

0 Kudos
Reply

960 Views
jays
Contributor II

Xiangjun,

Thank you for the reply.

CAN is fine in this configuration unless you set some bits like loop back, monitor... The receive side of the interface monitors the transmit bits to see if there is bus contention but does not but the data into the receive buffer.

There is also the fact that code written with the older SDK can.c and can.h they used to validate the hardware works. That code just transmits CAN frames on CAN0 and receives them on CAN1, it does all that locally and has nothing else going on. Only real difference I see is the old code uses CAN_SetRxBufferConfig() and CAN_TransferReceiveNonBlocking(), with the MCAN drivers I am using MCAN_SetRxFifo0Config() and MCAN_TransferReceiveFifoNonBlocking(), there is no MCAN_TransferReceiveNonBlocking().

Thank you.

Jay S.

0 Kudos
Reply