Hi, we notice that when the Jetson nano cameras are unplugged (or momentarily loose contact because of vibrations) our entire Jetson nano system crashes and reboots. While we obviously will try to keep the cables more robust for our use case, is there a way to make a detachment less catastrophic? Our system shouldn’t completely crash and reboot just because a camera was disconnected.
hello anonymous510,
actually, you cannot unplugged CSI camera sensor while it’s streaming.
VI engine expect the MIPI signaling coming continuously without errors, and you’ll see sync-point timeout reported due to camera disconnected.
sync-points is used to communicate with sensor hardware to waits for sensor stream, it’ll keep waiting and report timeout failures permanently, the user-space also pending there for the mutex lock. this low-level error eventually crash the kernel and led to system reboot.
however,
there’s software implementation to add error event handling , i.e. EVENT_TYPE_ERROR.
please moving your JetPack release to the latest version, (i.e. JetPack-4.5 / l4t-r32.5) to include the driver update.
you should also refer to Multimedia API Sample Applications,
this is user-space to handle the error event and shutdown the application gracefully.
please refer to below samples and include the error handling to your applications.
for example,
Argus/samples/userAutoExposure
} else if (iEvent->getEventType() == EVENT_TYPE_ERROR) {
const IEventError* iEventError =
interface_cast<const IEventError>(event);
EXIT_IF_NOT_OK(iEventError->getStatus(), "ERROR event");
Thank you for the very detailed and technical explanation. This is super helpful.
We are not using the Jetson API directly, but rather a gstreamer pipeline via nvarguscamerasrc. Is this something that should be handled by nvarguscamerasrc? Will updating to the latest jetpack include a nvarguscamerasrc that has this error handling? Or alternatively, is there anything we can do keep using a gstreamer pipeline and get graceful error handling/shutdown without a kernel crash?
hello anonymous510,
you should moving to the latest JetPack release to include the driver update.
to emphasize,
please first to consider keep the cables more robust for your use-case, since it’s the root cause.
thanks