Jetson TX2 NX PXL_SOF

Hello everyone,
I’ve been running into the error “PXL_SOF syncpt timeout! err = -11” and I’m trying to understand why I cannot get rid of that.

My first doubt is whether the width and height should include vertical and horizontal blanking or not.

I’m asking this because, even after reading the TRM descriptions for FRAME_X, FRAME_Y, OUT_X, OUT_Y and after trying to use both it’s still not clear to me which is the correct choice.

Best Regards,
Juan Pablo.

Suppose it depend on sensor.
It’s could be better consult with vendor.
You may reference to below for some Sony sensor’s case. Also you may need to check the trace log for the root cause of the PXL_SOF.

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/camera_sensor_prog.html#wwpID0E0F50HA

Hi @ShaneCCC,

Suppose it depend on sensor.

No it doesn’t, the Jetson TX2 VI/CSI blocks should always follow the same working principle regardless the sensor.

You may reference to below for some Sony sensor’s case.

I already referenced that when I made the same sensor work on a Jetson Nano with the same custom baseboard.

Also you may need to check the trace log for the root cause of the PXL_SOF.

Kind of a pain in the ass but I may have no other choice since a lot of this things don’t go to dmesg.


Now, could yo please answer my original question?

I’d like to know whether the TX2 expects me to configure (for any possible sensor under the sky) the active image dimensions or the complete image dimensions (including blanks).

That very same parameters are used in the following piece of code extracted from vi4_fops.c

vi4_channel_write(chan, vnc_id, FRAME_X, width);
vi4_channel_write(chan, vnc_id, FRAME_Y, height);
vi4_channel_write(chan, vnc_id, SKIP_X, 0x0);
vi4_channel_write(chan, vnc_id, CROP_X, width);
vi4_channel_write(chan, vnc_id, OUT_X, width);
vi4_channel_write(chan, vnc_id, SKIP_Y, 0x0);
vi4_channel_write(chan, vnc_id, CROP_Y, height);
vi4_channel_write(chan, vnc_id, OUT_Y, height);

I already know the Nano expects the active image dimensions (or at least works fine with them).
That way doesn’t work on the TX2 NX right now and that’s why I’m asking.
I’d like to confirm if the configuration for those parameters should be the same.

Best Regards,
Juan Pablo.

Due to TX2 will check the sensor output lines and frames must to match the report size but Nano didn’t do the checked that is why if you driver report more or less few lines/frames that wouldn’t have problem on Nano. However TX2 will check if less or more will alert error. Also the active image dimension may not always the same with the output lines/frames that’s why I said it depend on sensor. Usually it maybe few lines/frames than the active dimensions.

Hi @ShaneCCC,
So the TX2 dimensions should match the total number of pixels (expressed as lines and line_length) output by the sensor, regardless of the size of the active region, right?

Best Regards,
Juan Pablo.

Yes, the output size must exactly as driver report for TX2 and Xavier.
But the line_length is doesn’t matter with the output size(lines/pixels)

Hi @ShaneCCC,
I’ve been failing for two weeks with this issue, checking every possible parameter and trying every possible combination.

Things won’t work regardless of what you try unless you enable the TPG.
With the TPG enabled I can use the same configuration as the Jetson Nano.

The problem is that enabling the TPG is not exactly a solution and smells of a bug in the drivers.

Best Regards,
Juan Pablo.

You should check the trace log may get more information to tell what going on.

HI @ShaneCCC,
I spent a week looking at other people’s trace logs and checking about every single suggestion on this forum.
I then spent another week looking at my own trace logs and the suggestions on this forum.

I’d get crc errors, frame short errors, line short errors, ecc errors and the list goes on.
I got to the point where it was impossible to have such errors and yet the trace would still show them.

The only single things that made a difference at all is the tpg.

You pick the exact same hardware with the exact same dts and exact same options for everything except that the tpg is enabled and it will work.
You pick the exact same hardware with the exact same dts and exact same options for everything except that the tpg is disabled and it won’t work.

So now I’m trying to find what the real difference would be for the tpg to fix something that is supposedly unrelated.

Best Regards,
Juan Pablo.

Have apply the patch from below topic for ECC/CRC disabled to try.

Hi @ShaneCCC,
I already tried that one last week (about ten times), so I know for a fact that it doesn’t fix the issue.

Best Regards,
Juan Pablo

OK, then I run out of idea for this case now.

Hi @juan.tettamanti,

Could you share the logs you are getting when activating traces?

When I’ve developed drivers, in the active_w, I had configure the width of the active image and in the line_length entry the full line output including horizontal blanking. In the active_h, I’ve had to sometimes modify the active image size given by the sensor, as this is sensor dependent, sometimes the image will just come with more pixel lines, in theory the traces logs should tell you that as an error.

Best regards,
Roberto