My customer is using our MCAL 4.0.3 with the MPC5777C and they are trying to enable both the FlexCAN and MCAN interfaces. The MCAN modules will be configured for CAN-FD and the FlexCAN modules will be used for classic CAN.
The problem that we are running into is that it appears that the MCAL driver for both the FlexCAN and MCAN interfaces is common and there appears to be no way to distinguish between the two interfaces. Therefore, the customer cannot configure both the FlexCAN and MCAN interfaces together. Currently, the customer must configure all 4 FlexCAN modules and then assign 2 of the interfaces to MCAN manually. (see below)
What I’m doing currently is configuring all 4 FlexCANs (A, B, C, and D) and configuring them so HrH 0 and 1 (zero indexing) are the Pins that we are using for MCAN. This allows the two other Flex Channels to be 2 and 3. If I didn’t do this there’d be an Hrh 0 and 1 for both Flex and MCAN but you’d not be able to tell which is which in the code.
The customer is wondering if we will have a hotfix to address this? or if there is a better way to enable all 4 FlexCAN modules and also the 2 MCAN modules.
Solved! Go to Solution.
in the latest MCAL4.0 release (MPC5777C_MCAL4_0_RTM_1_0_1) there are provided two CAN drivers:
CAN (c:\NXP\AUTOSAR\MPC5777C_MCAL4_0_RTM_1_0_1\eclipse\plugins\Can_TS_T2D41M10I1R0) and
The CAN driver is used to configure FlexCAN modules (all 4 are supported) and MCAN driver is used to configure MCAN modules (all MCAN1 and MCAN2 supported).
So MCAL supports both FlexCAN and MCAN modules from version MCAL4.0 version 1.0.1. If customer is using older version 1.0.0 there was supported only FlexCAN.
Thank you for the feedback but this doesn't address the problem that the customer is facing. Here is the comment from the customer:
Unfortunately, this isn’t the issue. I have both FlexCAN and MCAN working.
The problem is that the identifier used by MCAL (Hrh – Hardware Receive Handler) does NOT distinguish between FlexCAN and MCAN.
The Hrh is required, by MCAL, to be continuous numbering per CAN (so it has to start at 0 for both MCAN and FlexCAN). This means if you use the four FlexCAN you’d have 0 through 3. Then if you use the 2 MCAN you’d have 0 through 1. The Interrupt Callback function used for receiving the CAN message includes an Hrh identifier, so you can determine which CAN bus your message is received on, and is common between FlexCAN AND MCAN. Thus 0 and 1 FlexCAN look like 0 and 1 MCAN. Per the person Steve contacted about this initially:
“Actually our CAN driver has to be updated also to invoke corresponding call back function. Does the customer need a HF for this or they can use their workaround?”
So what is being said there is there isn’t a separate callback function that corresponds individually between MCAN and FlexCAN. It’s shared. This is where the problem is. The solution, or my guess on the solution, is that the Static CAN file, this is one that is NOT generated through the MCAL but provided by NXP, needs to have a second callback function added that will be used for MCAN while the initial one is used for FlexCAN.
I know this is a problem because I only had 1 CAN hooked up at a time. I sent a message on my Bus 4 (Hrh 0 for MCAN), and it was identified as 0 Hrh, but so was the receive message that was received on my Bus 1 (Hrh 0 for FlexCAN).
My workaround for this problem only works because I’m only using 2 FlexCAN and 2 MCAN. I’m simply creating MCAL references for all 4 FlexCAN and then only the ones for FlexCAN 2 and 3. This leaves 0 and 1 to be used for MCAN because I’m never used 0 and 1 for FlexCAN in the code. If I only established references for 2 FlexCAN, I’d have duplicate 0 and 1 Hrh numbers and wouldn’t be able to know which 0 CAN I was receiving a value on. If I wanted to use more than 2 FlexCAN, this workaround wouldn’t work.
The other solution is to allow the Hrh values to be shared between FlexCAN and MCAN so that if you use 0 and 1 MCAN you can then continue on with 2 and 3 for FlexCAN. This allows for unique numbers regardless of the CAN being used. However, I would guess this approach would be much harder to implement.
Can you let me know if there is a hot fix planned to address this or is there a more graceful workaround?