Hi Frantisek,
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?
Thanks,
Peter
