topic Re: IMX 53 CAN0 receive stops when using IPU in i.MX Processors

IMX 53 CAN0 receive stops when using IPU

chadgreenebaum — Thu, 19 Dec 2013 01:52:57 GMT

We are doing a project that uses both CAN bus and the VPU and IPU for video. Video is coming in from a UVC camera being decode from mjpeg using the VPU and then the IPU is used to do a crop, scale, rotate, colorspace change and display to fb0. When mxc_ipu_lib_task_buf_update is called to display frames we lose communication from CAN0, CAN1 continues to function normally.

Has anyone seen this before or have any idea what could be the cause?

Re: IMX 53 CAN0 receive stops when using IPU

alejandrolozan1 — Fri, 03 Jan 2014 14:31:02 GMT

Hi,

I have never seen this behavior before. Can you share more information about how to reproduce the problem and maybe share code of your application.?

Best Regards,

Alejandro

Re: IMX 53 CAN0 receive stops when using IPU

TomE — Fri, 07 Feb 2014 00:58:12 GMT

Do you mean you lose all communication on CAN0 or do you start losing some CAN frames?

What speed is your CAN network. You shouldn't have any trouble on slow (33kHz) CAN buses, but you can expect problems with this software at 500kHz or 1MHz.

What does ifconfig show? Is the interface still "up"?

Do you have network statistics visible under "/sys/class/net/can0/statistics"? What do they show?

On our board with two 1MHz CAN buses, we lose CAN messages when we had a lot of Ethernet traffic. This is because the CAN drivers use "NAPI", and don't actually read any data from the absolutely time-critical and unbuffered CAN hardware. Reading the messages from the CAN registers is postponed until a background task. In contrast, the Ethernet driver will happily forward hundreds of packets from within its interrupt routine, locking out everything else (and the CAN interrupts and data-reading task) for many milliseconds.

Then there are the "mystery times" when for no apparent reason the Kernel decides to block all tasks (including the NAPI ones) for a few milliseconds. Recompiling the kernel without the default diagnostics that we had helped with this.

This is compounded by the platform code we have (YMMV) not enabling any interrupt priority setting. Due to the default ordering, Ethernet gets priority over CAN.

I had to change the platform code to enable interrupt priority, AND rewrite the CAN drivers to have them read the data into a ring buffer during the interrupt to have them work reliably.

Tom