SHORT_FRAME issue cause crash in nvarguscamerasrc but issue does not appear with v4l2

Hi all,

I have been debugging an issue with nvarguscamerasrc in JP4.4.

I am moving a servomotor through i2c, this motor is totally independent of the cameras.

The issue comes up when I capture from the camera using nvarguscamerasrc and then I move the motor.

This issue does not happen with capturing with v4l2-ctl, and also it does not happen using nvcamerasrc and JP3.2.1. The issue started to appear when we did the porting to JP 4.2.2 and it is still happening with JP 4.4.

enabling the trace for checking the nvarguscamerasrc failure when moving the motor:

 kworker/0:2-9310  [000] ....  1599.166338: rtcpu_vinotify_event: tstamp:50114864474 tag:ATOMP_FE channel:0x00 frame:101 vi_tstamp:50114863713 data:0x00000000
 kworker/0:2-9310  [000] ....  1599.166341: rtos_queue_peek_from_isr_failed: tstamp:50114884604 queue:0x0b4b4500
 kworker/0:2-9310  [000] ....  1599.166342: rtcpu_vinotify_event: tstamp:50114933634 tag:CHANSEL_PXL_SOF channel:0x00 frame:102 vi_tstamp:50114933141 data:0x00000001
 kworker/0:2-9310  [000] ....  1599.166342: rtcpu_vinotify_event: tstamp:50114934019 tag:ATOMP_FS channel:0x00 frame:102 vi_tstamp:50114933143 data:0x00000000
 kworker/0:2-9310  [000] ....  1599.166343: rtcpu_vinotify_event: tstamp:50114934134 tag:CHANSEL_LOAD_FRAMED channel:0x10 frame:102 vi_tstamp:50114933792 data:0x08000000
 kworker/0:2-9310  [000] ....  1599.222290: rtcpu_vinotify_event: tstamp:50115426244 tag:CHANSEL_SHORT_FRAME channel:0x04 frame:106 vi_tstamp:50115425671 data:0x00000004
 kworker/0:2-9310  [000] ....  1599.222293: rtcpu_vinotify_event: tstamp:50115426457 tag:ATOMP_FE channel:0x02 frame:106 vi_tstamp:50115425672 data:0x00000000
 kworker/0:2-9310  [000] ....  1599.222296: rtos_queue_send_from_isr_failed: tstamp:50115433429 queue:0x0b4a7258
 kworker/0:2-9310  [000] ....  1599.222296: rtos_queue_send_from_isr_failed: tstamp:50115433538 queue:0x0b4aad68
 kworker/0:2-9310  [000] ....  1599.222297: rtos_queue_send_from_isr_failed: tstamp:50115433647 queue:0x0b4ac998
 kworker/0:2-9310  [000] ....  1599.222298: rtos_queue_send_from_isr_failed: tstamp:50115433753 queue:0x0b4ae518 

I am also seeing the SHORT_FRAME message in the debug messages for nvargus-daemon.

With v4l2-ctl there are no issues when capturing and moving the motor, on the trace everything goes correctly.

I also added debug to the TX2 capture subsystem it seems that V4L works different as nvargus does, I see messages from the capture subsystem of each buffer dequeued using V4L but for nvarguscamerasrc I do not see any message from the capture subsystem it only starts the stream.

It seems like nvargusdaemon handles the dequeue method when using nvarguscamerasrc to dequeue buffers, is that right?

Do you know what can be causing this issue?


Would like to know if the issue is specific to using gstreamer. Could you try the jetson _multiemdia_api sample?


Hi DaneLLL,

I have tried that sample and the same issue appears.


It’s could be the sensor gain/exposure/frame rate control function do something cause the short frame error. You may try to modify the sensor driver to have those function as dummy to check it.

Hi ShaneCCC

I did the test you mentioned with dummy gain/exposure/framerate controls but the issue appeared. I also set the gain and exposure to the minimum camera value supported (both gain and exposure), also to the maximum but no success.

It is interesting that with v4l2-ctl the issue does not appear. there are no issues on the vi trace when using v4l or using nvcamerasrc neither (JP 3.2.1).


Can you try to modify the active_h in device tree to narrow down it.