LPC54616 Max. CAN FD Rate

[jays]

Hello,

I've been working with the LPC54616 CAN interfaces using the MCAN driver. The board I'm working with has a 12 MHz crystal and I'm using the PLL (BOARD_BootClockPLL180M) to boost the clock rate to 180 MHz.

I've implemented a number of CAN FD bit rates without problem. For CAN FD with a split rate I get 1 MBit/Sec - 3 MBit/Sec without issues.

Right now I'm trying to bump that up to 5 MBit/Sec for the data but haven't been successful. I haven't been able to find any clocking/speed specs on the LPC54616 CAN interfaces. I've tried a number of different dividers, segment values with the jump set to 3. So does someone know what the maximum bit rate for CAN FD data is or if 5MBit/Sec is possible?

Thanks in advance.

Jay S.

[gunnarbohlen]

Hello Jay,

something else to consider:

you say that you run the CPU at 180MHz.

For CAN-FD the recommended can-core clock is 80MHz (or 40/20MHz). With a higher core clock you get more tq's, but for a stable communication with other CAN-nodes it is very important to match ths samplepoint of nominal bitrate, because bit rate switch is done at the sample point of BRS bit (not at the end of this bit) BRS bit is a mixture of nominal bitrate up to the sample point, then continues with TSEG2 of data bitrate. With a different CAN-Core clock you *might* not be able to set up the nominal bitrate with the exact samplepoint, and in case of high scale between nominal and data bitrate (e.g. 500k /5M) you might get communication errors because of a sample point that is too far away from the ideal sample point.

In our design we use the LPC54618, and run the CPU with 160MHz.

Changing the core clock might be a big issue if everything is nearly finished and tested... :-)

[jays]

I had time to dump and look at the error registers and saw the TX and RX were not matching so the interface would try to recover from that. I had the HW tech put put some more scope hook up points on the board and looked at the relationship between the TX and RX signals. The propagation delay through the driver chip (TJA1052i) was considerable (128ns on my test board) and the sample point on the RX was not in the proper place.

Got in and programmed up the TDCR register and things started to work. So if you have issue with high data rates check the TX->RX delay and program the TDCR register.

Documentation for the TDCR and Transmit delay compensation in the LPC54616 User Manual (UM10912) isn't that great. There is a mixture of names for the signals (or maybe pins) in section 35.14.2, CANx_TD, CANx_RD, CAN1_RD, m_can_tx, m_can_rx, MCAN_RX which makes things confusing. Think Fig 137 might be wrong too, think that the bottom m_can_tx might be m_can_rx.

Jay S

[jeremyzhou]

Hi Jay Schwichtenberg

Thank you for your sharing and the suggestions about the RM.
I agree with you, the bottom m_can_tx should be m_can_rx, I'll report it for Document team for checking.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[jeremyzhou]

Hi Jay Schwichtenberg,

Thanks for your reply.
Q1) So does someone know what the maximum bitrate for CAN FD data is or if 5 MBit/Sec is possible?
-- CAN FD (CAN with flexible data rate) is an extended version of the well-known "classic" CAN (8 data bytes and 1 Mbit/s data rate),  CAN FD networks currently enable productive use with 8 MBit/s, whereby the CAN FD standard permits up to 15 Mbit/s.
So it's available to configure the CAN FD module to transfer and receive data at 5 MBit/s, and I was wondering if you can introduce the testing process you did, for instance, demo code, valuation board, etc.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[jays]

jeremyzhou,

Thanks for you response.

Yes the CAN FD spec has the 12 MBits/Sec rate but I haven't been able to find anything on what the LPC54616 can do. We are running on a custom board and the limiting factor is the CAN drivers used in the circuit which are rated to 5 MBits/Sec.

We are running the MCU with a 12 MHz crystal and have the internal clock set at 180 MHz using the PLL. The processor is an A1 rev. For testing port 0 is connected to port 1 for looping back.

I've coded the system to use fix bit rates from a table which required modifying MCAN_Init pulling out MCAN_SetBaudRate and MCAN_SetBaudRateFD and calling MCAN_SetArbitrationTimingConfig and MCAN_SetDataTimingConfig directly with values from my timing table. This works with 42 bit rate combinations up to 1 MBits/Sec arbitration rate 3 MBits/Sec data rate.

The timing config structures with a master clock divider of 3 that give me the best results are (arbitration, data):

{  2,  3, 12,  5 }, {  0,  3,  7,  2 }

Validation:

1000000 = 180000000 / (3 * (2+1) * (12+5+3))

5000000 = 180000000 / (3 * (0+1) * (7+2+3))

With this timing configuration every thing looks good until the DLC field in the transmitted frame. The DLC field is not correct and no valid data is transmitted after the DLC field with it trying to resync after that.

Here is a dump of the port 0 and port 1 registers in the open routine I use with a dump of the frame in the TX message buffer (T0, T1 and data). This is just before the enable routine is called in the open routine.

CHANNEL: 0
MAINCLKSELA: 0x00
MAINCLKSELB: 0x02
FROCTRL: 0x00A45763
SYSPLLCLKSEL: 0x00
CAN0CLKDIV: 0x00000002
CAN1CLKDIV: 0x40000000

DBTP: 0x00000723
TEST: 0x00000080
CCCR: 0x00000303
NBTP: 0x06020C05
TSCC: 0x00000002
TSCV: 0x0000E3CD
TOCC: 0xFFFF0000
TOCV: 0x0000FFFF
ECR: 0x00000000
PSR: 0x00000707
TDCR: 0x00000000
IR: 0x00010000
IE: 0x03800000
ILS: 0x00000000
ILE: 0x00000001
GFC: 0x00000000
SIDFC: 0x00000000
XIDFC: 0x00000200
XIDAM: 0x1FFFFFFF
HPMS: 0x00000000
NDAT1: 0x00000000
NDAT2: 0x00000000
RXF0C: 0x00010400
RXF0S: 0x00000000
RXF0A: 0x00000000
RXBC: 0x00000000
RXF1C: 0x00000000
RXF1S: 0x00000000
RXF1A: 0x00000000
RXESC: 0x00000707
TXBC: 0x01001600
TXFQS: 0x00000001
TXESC: 0x00000007
TXBRP: 0x00000000
TXBAR: 0x00000000
TXBCR: 0x00000000
TXBTO: 0x00000000
TXBCF: 0x00000000
TXBTIE: 0x00000000
TXBCIE: 0x00000000
TXEFC: 0x00000000
TXEFS: 0x00000000
TXEFA: 0x00000000
MRBA: 0x20010000
ETSCC: 0x800003BF
ETSCV: 0x0000EC5F
STDFLT:
0x20010000: 0x00000000
0x20010004: 0x00000000
0x20010008: 0x00000000
0x2001000c: 0x00000000
0x20010010: 0x00000000
0x20010014: 0x00000000
0x20010018: 0x00000000
0x2001001c: 0x00000000
EXTFLT:
0x20010800: 0x00000000 - 0x00000000
0x20010804: 0x00000000 - 0x00000000
0x20010808: 0x00000000 - 0x00000000
0x2001080c: 0x00000000 - 0x00000000
0x20010810: 0x00000000 - 0x00000000
0x20010814: 0x00000000 - 0x00000000
0x20010818: 0x00000000 - 0x00000000
0x2001081c: 0x00000000 - 0x00000000

CHANNEL: 1
MAINCLKSELA: 0x00
MAINCLKSELB: 0x02
FROCTRL: 0x00A45763
SYSPLLCLKSEL: 0x00
CAN0CLKDIV: 0x00000002
CAN1CLKDIV: 0x00000002

DBTP: 0x00000723
TEST: 0x00000080
CCCR: 0x00000303
NBTP: 0x06020C05
TSCC: 0x00000002
TSCV: 0x0000E61A
TOCC: 0xFFFF0000
TOCV: 0x0000FFFF
ECR: 0x00000000
PSR: 0x00000707
TDCR: 0x00000000
IR: 0x00010000
IE: 0x03800000
ILS: 0x00000000
ILE: 0x00000001
GFC: 0x00000000
SIDFC: 0x00000000
XIDFC: 0x00000200
XIDAM: 0x1FFFFFFF
HPMS: 0x00000000
NDAT1: 0x00000000
NDAT2: 0x00000000
RXF0C: 0x00010400
RXF0S: 0x00000000
RXF0A: 0x00000000
RXBC: 0x00000000
RXF1C: 0x00000000
RXF1S: 0x00000000
RXF1A: 0x00000000
RXESC: 0x00000707
TXBC: 0x01001600
TXFQS: 0x00000001
TXESC: 0x00000007
TXBRP: 0x00000000
TXBAR: 0x00000000
TXBCR: 0x00000000
TXBTO: 0x00000000
TXBCF: 0x00000000
TXBTIE: 0x00000000
TXBCIE: 0x00000000
TXEFC: 0x00000000
TXEFS: 0x00000000
TXEFA: 0x00000000
MRBA: 0x20020000
ETSCC: 0x800003BF
ETSCV: 0x0000E53A
STDFLT:
0x20020000: 0x00000000
0x20020004: 0x00000000
0x20020008: 0x00000000
0x2002000c: 0x00000000
0x20020010: 0x00000000
0x20020014: 0x00000000
0x20020018: 0x00000000
0x2002001c: 0x00000000
EXTFLT:
0x20020800: 0x00000000 - 0x00000000
0x20020804: 0x00000000 - 0x00000000
0x20020808: 0x00000000 - 0x00000000
0x2002080c: 0x00000000 - 0x00000000
0x20020810: 0x00000000 - 0x00000000
0x20020814: 0x00000000 - 0x00000000
0x20020818: 0x00000000 - 0x00000000
0x2002081c: 0x00000000 - 0x00000000

id: 0x7FF
frame: standard
error: active
frame size: 12
rate switch: 1
format: CAN FD
store events: no
marker: 0x45
0000: 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 >UVWXYZ[\]^_` <

Here are the oscillograms I used to validate timing and show the problem.

This one has the frame that was transmitted and shows the interface trying to resync in the MagniVue area (top).

Next one measures the timing of the sync, 11 bit ID of 0x7FF with 2 stuff bits. At 1 MBits/Sec that is 14 bits and 14 us.

Let's verify the width of the ESI bit to see if it is at 5 MBits/Sec (200ns).

With a 12 byte data payload the DLC value (0-800ns after the ESI bit) should be 0x9 but I'm seeing 0xC and then bad data (no 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60).

That's as far as I've gotten on this. Have not looked at the ACK/NACK on the other side or the dump of the interrupt and status registers yet.

Thank you.

Jay S.