AM3352: Spurius Can Interrupt

NOTE: For the problem to occur, the CAN bus must be loaded with a large volume of frames being transferred.

Hi,

Could you please describe more about how the CAN interface is closed? For example is the processor about to rebooted? Is the interface about to be used again. Is there still CAN traffic after the interface is closed?

Best Regards,

Schuyler

Hello everyone,

completing the original post, the problem occurs sporadically when the bus is under heavy activity of CAN frames.

Steps to reproduce:
1.1) The bus under heavy activity is being read with the "read" interface of libc and, eventually, is being written with the "write" interface.

1.2) After a certain period, the application stops to read and write the bus.

1.3) After stopping the read and write operations, an ioctl call is made to deactivate the CAN interface (~IFF_UP).

1.4) When the interface is reactivated with the ioctl operation (IFF_UP), the Kernel sporadically freezes for a few seconds, and during the freeze:
1.4.1) The CAN initialization gets stuck in the "c_can_open" function, i.e., before the complete initialization of the device;
1.4.2) The C_CAN_CTRL_REG register has the TEST bit set high;
1.4.3) The Kernel attempts to handle the interrupt and, upon identifying that the interrupt was not handled after a large number of attempts due to the absence of a handler, the main interrupt of the CAN device is disabled.
1.4.4) After a few seconds, the Kernel proceeds with the initialization correctly.

2) Identified workaround:
2.1) We identified that if the interrupt handler is configured before starting the bus in "c_can_open", the Kernel can complete "c_can_open" without any failure.

3) Is there any suggestion to work around this scenario without needing to modify the Linux Kernel?

Best regards, Wagner Popov

Wagner Popov is on the same team as me, with the information he provided, can he help us?