fsl_flexcan hangs on startup

[stp_s]

Dear NXP support team,

I am using i.MX8M Plus device running freeRTOS on the M7 core. The M7 is integrating the fsl_flexcan library to run CAN communication interrupt based (TX and RX-fifo). The M7 core is commanded by the A53 core (remoteproc).
I noticed that FLEXCAN_TransferCreateHandle() (used during setup of flexcan) sometimes does not return, it is stuck on the first EnableIRQ() call. This only happens if external devices are sending frames at the time the flexcan is initialized.
I found two solutions to solve this problem:
1) reboot the entire i.MX8M Plus device after stopping the M7 core.
2) FLEXCAN_TransferCreateHandle() insert calls to NVIC_ClearPendingIRQ() for each interrupt enabled by EnableIRQ(), before EnableIRQ() is called.
Is this expected, or is there something wrong the way the library is used?

I do not see any calls to NVIC_ClearPendingIRQ() in case flexcan error flags are treated, e.g. FLEXCAN_ClearStatusFlags(). Is this expected? Unfortunately I do not have any setup for low level CAN bus negative testing.

[stp_s]

Dear Dhruvit Vasavada,
> "Yes, this is normal nothing wrong with the steps, because before enabling the EnableIRQ() if one clears all the rest pending interrupts then this would work totally fine."
Good!

> "if one clears a pending interrupt and then enableIRQ then this won't stuck"
The original fsl_flexcan does _not_ clear before enableIRQ, which causes enableIRQ to not return. Do you agree that a prior clear is required?

> "... cause the priority of the interrupt is changed now"
I have no idea what you mean by that, please explain!

Regards,
stp_s

[Dhruvit]

Hi @stp_s,

"The original fsl_flexcan does _not_ clear before enableIRQ, which causes enableIRQ to not return. Do you agree that a prior clearance is required? "
-> yes, pending interrupt clear is required if you do not clear them then those frames will gonna come from an external device, and then again this will stick like that.

"... cause the priority of the interrupt is changed now"
->That is because in case If an interrupt takes place but cannot be executed immediately (for instance, if another higher-priority interrupt handler is running), it will be pended. and in that case, priority can change.

I hope that makes your doubt clear.

Thanks & Regards,
Dhruvit Vasavada

[Dhruvit]

Hi @stp_s,

I hope you are doing well.

Can you please share the source code or code change for further debugging?

Thanks & Regards,
Dhruvit Vasavada

[stp_s]

I added lines 3527 to 3532. Without, program exececution stopped on first EnableIRQ() call at line 3535.

[Dhruvit]

Hi @stp_s,

I hope you are doing well.

Yes, this is normal nothing wrong with the steps, because before enabling the EnableIRQ() if one clears all the rest pending interrupts then this would work totally fine.

if one clears a pending interrupt and then enableIRQ then this won't stuck even if the external devices are providing the frames, cause the priority of the interrupt is changed now.

Thanks & Regards,
Dhruvit Vasavada