RT1064 FlexCAN3 (CAN FD) issues

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

RT1064 FlexCAN3 (CAN FD) issues

1,047件の閲覧回数
buescher
Contributor II

Those experimenting with CAN FD on an i.MX RT1064 or similar will have noticed that the 'Enhanced' registers of the CAN FD capable 'FlexCAN3' peripheral are either not implemented at all, or are not working properly (as far as know on 2019-09, this concerns the 'Enhanced FIFO' and the 'Enhanced bit timing registers', they all throw HardFaults when trying to acess them).

So we have to stick to the 'Extended' bit timing registers, which have less "bits" for the CAN timing segments tSeg1, tSeg2. The result is relaively coarse (and few) time quanta for each CAN / CAN FD data bit, especially for combinations with a low bitrate for the arbitration phase (e.g. message ID sent at 500 kbit/sec) and high bitrate for data (say 4 Mbit/sec). CiA (CAN in Automation), but also NXP themselves recommend to use THE SAME prescaler setting for both phases. In the RT1064 Processor Reference Manual Rev 0.1 on page 2768, there's a tiny note in the description of the CAN FD bit timing register ("FDCBT") which says:

> NOTE: To minimize errors when processing FD frames, use the same value for FPRESDIV and
> PRESDIV (in CAN_CBT or CAN_CTRL1).

This is easier said than done when the 'Enhanced' registers (with more bits for the propagation segment, tSeg1, and tSeg2) are absent, or don't work as described in the reference manual (Rev 0.1). In fact, I have got the 500 / 4000 kBaud combination working to some degree, but the CAN FD "brs" (bitrate switch) causes an awful lot of error frames that always arrive in bursts, and the sending note sets its "ESI" (error state indicator) bit in the CAN FD frame very often.

But there's another strange effect: My first steps with CAN FD on an RT1064 were based on the 'CANFD interrupt transfer' demo, which uses a "debug console" using LPUART1. I removed the debug console because I don't use it, and the UART will be occupied for other tasks later. This caused FlexCAN3 to stop working ! After spending hours searching for all kinds of reasons, the problem could be narrowed down to the following:

Before initialising "CANFD/FlexCAN3", it's not enough to call CLOCK_EnableClock() for the FlexCAN unit... it seems to be necessary enable the clock for LPUART1 (at least for FlexCAN3) by setting the 2-bit-group "CG12" in register "CCM_CCGR5" by either of the two commands (but basically do the same):

       CLOCK_EnableClock(kCLOCK_Lpuart1);

or

      CCM->CCGR5 |= 3 << (2 * 12); // set 2-bit-group "CG12" alias "lpuart1_clk_enable" in register "CCM_CCGR5"

Without this, the initialisation code for FlexCAN3 got stuck when trying to enter or exit from 'Freeze' mode (that's the only mode in which you can configure certain registers in any FlexCAN unit).

The effect was verified as follows:

Pause the RT1064 via debugger, then (in Keil's "Peripheral") view, clear 2-bit-group "CG12" in "CCM_CGR5", let the RT1064 continue

      -> no more CAN FD transmissions from FlexCAN3,
            CAN frames pending for transmission (in the TX buffer) don't get transmitted.

Pause the RT1064 via debugger again, *set* 2-bit-group "CG12" in "CCM_CGR5" to '3' = "enable LPUPART1 clock" in Keil's "Peripheral" view, let the RT1064 continue again

    -> et voila, FlexCAN3 is able to transmit messages again.

I hope this "observation" can save fellow developers some time... to summarize : Even if you use LPUART1 or not, enable its clock in the CCM unit, before initialising FlexCAN3, and keep that peripheral clock enabled.

I also hope that NXP comes up with a Processor Reference Manual (for the RT1064) that really matches the registers inside the chip (this doesn't only apply to FlexCAN1 / 2 / 3).

Best regards,

   Wolfgang .

  (keep this thread open for other 'observations' related to the RT106x's CANFD/FlexCAN3 unit... e.g. how to realize "good" bit timing combinations for CAN FD with high data bitrate / arbitration bitrate ratios without the non-functional 'Enhanced' timing registers, which currently give some headaches here)

0 件の賞賛
2 返答(返信)

929件の閲覧回数
jeremyzhou
NXP Employee
NXP Employee

Hi Wolfgang Buescher,

Thank you for your interest in NXP Semiconductor products and
for the opportunity to serve you.
Firstly, thanks for your sharing, I was wondering if you can upload the demo project which can replicate the phenomenon, as I'd like to do some testing on my side, in further, I'll contact the AE team for double-checking after I validate it.
Looking forward to your reply.

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.
-------------------------------------------------------------------------------

0 件の賞賛

137件の閲覧回数
mdkhaledibnhassan
Contributor I

For me sample interrupt is not working in RT1170 EVBK board. Cant transmit any data using sample interrupt app.

0 件の賞賛