IMX8QMMEK Surround View App - Camera and application stability issues

[mustafa_ozcelik]

I am testing imx8 surround view application using a iMX8QMMEK. However, although the application and the image (fsl-imx-xwayland, fsl-imx-qt5-validation-image) are standard with the 4.9.51_beta2 BSP, I am having difficulties with the application. I am using the standard device tree with HDMI output enabled, that is fsl-imx8qmmek-hdmi.dtb.

I have already ran the Surround View application (Surround View Application|NXP ) with success, the application that NXP developed as a proof of concept for automotive developments.

However, looking into the code a bit, I think that the software contains a lot of memory leaks and is pretty error-prone. I think that because of the fact that I noticed a lot off unchecked pointer operations, unchecked system calls and returns, careless usage of thread locks that block you to send a termination signal in some cases, causing a deadlock in the application.

Let alone, it does not work every time you launch the application.

I plug my 4 cameras (1280x800) through a serializer and plug it in the imx8qmmek. However, the cameras get very hot after a couple of minutes. If you run the application for about 20 minutes, the application freezes. When you relaunch the application, this time cameras are not opened correctly (white display), with no error whatsoever in the application logs. Additionally sometimes I get ioctl `VIDIOC_G_PARM` failed. These issues are often solved after a reboot, for a while, until cameras decide to suddenly stop working again. I need some help regarding understanding why this happens, and how to solve it. Also, reproduction is pretty hard, as camera problem can occur even after a reboot sometimes.

To me there are two possible reasons:
1) The application does not clean up enough resources before exiting the application, or before each iteration.

2) Problems with the camera interface, driver or device-tree.

I'd appreciate if I could get some help regarding the aforementioned problems. Thank you very much in advance.

Additional: memcheck / valgrind summary after running for a few minutes:

$> valgrind --track-origins=yes --leak-check=full ~/App/Build/SV3D-1.1
==5061== HEAP SUMMARY:
==5061==     in use at exit: 455,157 bytes in 154 blocks
==5061==   total heap usage: 361,224 allocs, 361,070 frees, 189,148,035 bytes allocated
==5061==
==5061== 158 bytes in 2 blocks are definitely lost in loss record 2 of 9
==5061==    at 0x48452D0: realloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==5061==
==5061== 432 bytes in 6 blocks are definitely lost in loss record 3 of 9
==5061==    at 0x48450D8: calloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==5061==
==5061== 63,116 bytes in 2 blocks are possibly lost in loss record 8 of 9
==5061==    at 0x484304C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==5061==
==5061== 384,202 (382,692 direct, 1,510 indirect) bytes in 38 blocks are definitely lost in loss record 9 of 9
==5061==    at 0x484304C: malloc (in /usr/lib/valgrind/vgpreload_memcheck-arm64-linux.so)
==5061==
==5061== LEAK SUMMARY:
==5061==    definitely lost: 383,282 bytes in 46 blocks
==5061==    indirectly lost: 1,510 bytes in 56 blocks
==5061==      possibly lost: 63,116 bytes in 2 blocks
==5061==    still reachable: 7,249 bytes in 50 blocks
==5061==         suppressed: 0 bytes in 0 blocks
==5061== Reachable blocks (those to which a pointer was found) are not shown.
==5061== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==5061==
==5061== For counts of detected and suppressed errors, rerun with: -v
==5061== ERROR SUMMARY: 4030008 errors from 651 contexts (suppressed: 0 from 0)

[mustafa_ozcelik]

Further investigation revealed that mxc-isi driver is making cameras not plug and play.

That means, you remove one camera, you wont be able to use the other four until rebooting.

At least this is what happens in my experience. You are not even able to stream with gstreamer if the camera connection is lost once, or unplugged.

Freeze issue still remains a mystery for me.

[gusarambula]

Hello Mustafa Ozcelikors,

My apologies for the delay. I asked our experts and they haven’t been able to reproduce this problem of the app freezing. They tested for six hours and it worked okay. The cameras were warm but not hot.

They used Linux imx8qmmek 4.9.51-8qm_beta2_8qxp_beta+g423d942 to test the SW. Application accesses to cameras through V4L2.

It could be that this is a hardware or power supply problem. As you wrote cameras are not plug and play and if camera connection is lost in any reason the camera output is frozen and camera is not released until rebooting.

Did you used the same Yocto image? If you used another image of the BSP please let us know so we can try to reproduce the error.

Regards,