S32K144 SDK 2.0.0 FlexCAN: trouble resuming CAN activity

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

S32K144 SDK 2.0.0 FlexCAN: trouble resuming CAN activity

Jump to solution
1,616 Views
Joao_Roscoe
Contributor III

Hi all,

I suceeded coding the basics and have interrupt driven TX and RX working (no can_pal, I'm using the flex_can driver directly, with classic message buffers, no FIFO), and exchanging data with a PC connected CAN USB adapter, for testing.

However, whenever I physically disconnect and reconnect the CAN bus, the CAN peripheral seems to stop working Restarting the system solves that.

I suspect that, after reconnectiong the bus, I need to reenable interrupts for all MB that are in BUSY state. Does it seem to be a good guess? If so, what would be the best way to achieve that?

Best regards,

Joao

Labels (1)
Tags (1)
1 Solution
1,266 Views
PetrS
NXP TechSupport
NXP TechSupport

Hi Joao,

it could be fine is you specify your issue in more details. Do you test the behavior on NXP board? Probably you have own code, can you share it, so we can see how the driver is used?

Do you disconnect bus during transmission/reception or when bus is idle and then for example try to send anything?

When FlexCAN stops working, what kind of errors are indicated (see ECR, ESR1 registers). Is still the MB interrupt enabled in IMASK1 register? Do you use Abort function too?

The BUSY status usually means previous enabled MB transmission/reception did not finish, e.g due to missing ACK. In such case MB interrupt is not called and internal MB status cannot be changed. However after bus is reconnected this waiting transmission is ACKed and MB interrupt should be finally called.

If using non-blocking functions you should always use FLEXCAN_DRV_GetTransferStatus() to know if new Send/Receive function can be called.

BR, Petr

View solution in original post

2 Replies
1,267 Views
PetrS
NXP TechSupport
NXP TechSupport

Hi Joao,

it could be fine is you specify your issue in more details. Do you test the behavior on NXP board? Probably you have own code, can you share it, so we can see how the driver is used?

Do you disconnect bus during transmission/reception or when bus is idle and then for example try to send anything?

When FlexCAN stops working, what kind of errors are indicated (see ECR, ESR1 registers). Is still the MB interrupt enabled in IMASK1 register? Do you use Abort function too?

The BUSY status usually means previous enabled MB transmission/reception did not finish, e.g due to missing ACK. In such case MB interrupt is not called and internal MB status cannot be changed. However after bus is reconnected this waiting transmission is ACKed and MB interrupt should be finally called.

If using non-blocking functions you should always use FLEXCAN_DRV_GetTransferStatus() to know if new Send/Receive function can be called.

BR, Petr

1,266 Views
Joao_Roscoe
Contributor III

>>>If using non-blocking functions you should always use FLEXCAN_DRV_GetTransferStatus() to know if new >>>Send/Receive function can be called.

*That was the point* !!!

Since I was transmitting only once at each 10ms, I assumed it was safe to transmit without verifying the transfer status - and that was generally true. But with the bus disturbance, that was not true anymore.

Problem solved! Thank you very much for the tip.

Best regards,

Joao

0 Kudos