Xavier_NX FS_FAULT error with lattice crosslink

Hi Team,

We are working on Flir tau2 with Jetson Xavier NX, but we are following FS_FAULT error (End of Frame is not coming).

Connections are Flir_Tau2<=(cmos 14 bit)=>lattice_crosslink<=(csi_1_lane_raw_12)=>Nvidia_Xavier(Custom_driver).

Any Suggestions how to fix End_of_frame issue, or any alternative.

LOGS Are :

 kworker/0:4-3207  [000] ....   622.319767: rtcpu_vinotify_event: tstamp:19767533445 tag:CSIMUX_STREAM channel:0x00 frame:0 vi_tstamp:19767309369 data:0x00000100
 kworker/0:4-3207  [000] ....   622.431583: rtcpu_vinotify_event: tstamp:19770923489 tag:FS channel:0x00 frame:1 vi_tstamp:19770860917 data:0x00000012
 kworker/0:4-3207  [000] ....   622.431587: rtcpu_vinotify_event: tstamp:19770923633 tag:ATOMP_FS channel:0x00 frame:1 vi_tstamp:19770860918 data:0x00000000
 kworker/0:4-3207  [000] ....   622.431588: rtcpu_vinotify_event: tstamp:19770923794 tag:CHANSEL_PXL_SOF channel:0x23 frame:1 vi_tstamp:19770862905 data:0x00000001
 kworker/0:4-3207  [000] ....   622.431589: rtcpu_vinotify_event: tstamp:19770923931 tag:RESERVED_19 channel:0x23 frame:1 vi_tstamp:18487290720 data:0x08020001
 kworker/0:4-3207  [000] ....   622.487584: rtcpu_vinotify_event: tstamp:19771940872 tag:CHANSEL_PXL_EOF channel:0x23 frame:1 vi_tstamp:19771873824 data:0x01fe0002
 kworker/0:4-3207  [000] ....   622.487586: rtcpu_vinotify_event: tstamp:19771941015 tag:ATOMP_FRAME_DONE channel:0x23 frame:1 vi_tstamp:19771873839 data:0x00000000
 kworker/0:4-3207  [000] ....   622.487588: rtcpu_vinotify_event: tstamp:19771941173 tag:RESERVED_19 channel:0x23 frame:1 vi_tstamp:18519641024 data:0x02020001
 kworker/0:4-3207  [000] ....   622.487590: rtos_queue_peek_from_isr_failed: tstamp:19772161500 queue:0x0bcbcf78
 kworker/0:4-3207  [000] ....   622.599589: rtcpu_vinotify_error: tstamp:19775033497 tag:CSIMUX_FRAME channel:0x00 frame:1 vi_tstamp:19775031763 data:0x000000a2
 kworker/0:4-3207  [000] ....   622.599592: rtcpu_vinotify_event: tstamp:19775034785 tag:CSIMUX_FRAME channel:0x00 frame:1 vi_tstamp:19775031763 data:0x000000a2
 kworker/0:4-3207  [000] ....   622.599593: rtcpu_vinotify_event: tstamp:19775034948 tag:FS channel:0x00 frame:1 vi_tstamp:19775031763 data:0x00000012
 kworker/0:4-3207  [000] ....   622.599594: rtcpu_vinotify_event: tstamp:19775035089 tag:ATOMP_FE channel:0x00 frame:1 vi_tstamp:19775031764 data:0x00000000

Thanks
Alx

Hi Team,

It looks like that Lattice is dropping 1 line data, can we hack in Vi driver that it bypass that check, just for checking.

Because reducing the active_h(510) is creating PIXEL_RUNAWAY. and when giving active_h(511), then we are loosing 1 line.

Thanks
Alx

So the problem fixed?
BTW, from the trace log I didn’t see the FE also.

Also SPURIOUS data reported, that could be the lattice output some user defined data cause it.

kworker/0:4-3207 [000] … 622.319767: rtcpu_vinotify_event: tstamp:19767533445 tag:CSIMUX_STREAM channel:0x00 frame:0 vi_tstamp:19767309369 data:0x00000100

Hi Shane,

No, issue is not resolved.
Yes we are not gettinf FE as last line is missed.
Is there any way to skip last line. Basically skip FE.
Some time csimux frame issue comes but sometime not.

Loss the FE could be the cause of the FS_FAULT. Current don’t support to skip it.

So Any support from previous SDK or way to bypass it.
OR
we can add dummy EOF(FE) ?

As lattice side we are stuck and getting frame with less one line.

Can have lattice output FE package?

I think no, as we check after probing the signals.
FS is coming with data frames.

Hi Shane,

After probing the signals we also check that FE is not coming during probe.
It may be issue of timing too ? can we do some try on timing side.

Thanks
Alx

Hi Shane,

If we are not waiting for FE packet then we are able to capture frame using below command :

v4l2-ctl -d /dev/video0 --set-ctrl bypass_mode=0 --stream-mmap --stream-count=1 --stream-to=test.raw
(RAW File are attached)

And converted that raw file using hexeditor, and content looks like :

             00   01   02   03   04   05   06   07   08   09   0a   0b   0c 0d 0e 0f
0000000000 0xb8 0x89 0x00 0x0b 0xb9 0x98 0x00 0x0b 0xb8 0x89 0x00 0x0b 0xb9 0x99 0x00 0x0b
0000000010 0xb9 0x99 0x00 0x0b 0xb8 0x89 0x00 0x0b 0xb9 0x98 0x00 0x0b 0xb9 0x98 0x00 0x0b
0000000020 0xb9 0x99 0x00 0x0b 0xb9 0x99 0x00 0x0b 0xb9 0x99 0x00 0x0b 0xb8 0x89 0x00 0x0b
0000000030 0xb9 0x99 0x00 0x0b 0xb9 0x99 0x00 0x0b 0xb9 0x99 0x00 0x0b 0xb9 0x99 0x00 0x0b
0000000040 0xb9 0x99 0x00 0x0b 0xb9 0x99 0x00 0x0b 0xb9 0x99 0x00 0x0b 0xb9 0x99 0x00 0x0b
0000000050 0xb9 0x99 0x00 0x0b 0xb9 0x99 0x00 0x0b 0xb9 0x99 0x00 0x0b 0xb9 0x99 0x00 0x0b
0000000060 0xb9 0x99 0x00 0x0b 0xb9 0x99 0x00 0x0b 0xb9 0x99 0x00 0x0b 0xb9 0x99 0x00 0x0b
0000000070 0xb9 0x99 0x00 0x0b 0xb9 0x99 0x00 0x0b 0xb9 0x99 0x00 0x0b 0xb9 0x99 0x00 0x0b
.
.
.
.
000009fa80 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b
000009fa90 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b
000009faa0 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b
000009fab0 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b
000009fac0 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b
000009fad0 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b
000009fae0 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b
000009faf0 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b 0x90 0x0b

Total size of raw file are (640x511x2(byte) = 654080 (9faff)). So as per that it seams that 2 byte contains 1 pixel data,
Anycon-cal-30.raw (638.8 KB)

But we are not able to extract 12 bit data : bit confused here , As TRM says :

Can you guide as how to extract 1 pixel count from raw file.

Thanks
Alx

NX is using T_R16 that shift left one bit from T_R16_I

So for RAW12 we will remove bit15 and bit2 bit1 bit0 from data.

Remove bit0-3 i think

So if data is like above, then we will use
0xb8 0x89
and it will be
0x89 0xb8

and after removing 3 to 0 it will be

0x89 0x8

above is right ?

Thanks
Alx

Yes, should be like that.

it will be 0x89 0x8 or 0x89 0xb ?

Will be 0x89b

Thanks