Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XavierNX with IMX183 version above 0.12.3 #72

Open
PierrickIntom opened this issue Feb 26, 2024 · 5 comments
Open

XavierNX with IMX183 version above 0.12.3 #72

PierrickIntom opened this issue Feb 26, 2024 · 5 comments

Comments

@PierrickIntom
Copy link

PierrickIntom commented Feb 26, 2024

We've been using the driver version 0.12.3 for a long time to connect our two IMX183 sensors with a XavierNX and an Auvidea JNX30 carrier board. Recently, while flashing a new Jetson, I wanted to install the latest version of the driver, and I ran into a few problems:

1. Bytes per line
During the setup, I modify the device tree to enter the following values:
o physical_w = “13.056”; (the physical width and height values have been modified since version 0.12.3)
o physical_h = “8.755”;
o active_w = “5440”;
o active_h= “3648”;
o max_gain_val = “27000”;
o pixel_t = “gray”;
o max_framerate = “26800”;
o default_framerate = “26800”;
o max_exp_time = “10000000”;

After the flashing is finished, I check with v4l2-ctl --device /dev/video0 --all the parameters and here the Bytes per line number is 5632 instead of 5440.
bytes_per_line
And so, when I try to take images, nothing happens. In the dmesg, I see the message "No response from camera processor". How can I modify this Bytes per line number to match the width of the image, as we had before ?

2. Max exposure
Another issue that we previously had and that you helped us solve was related to the maximum exposure time for this sensor. When the exposure time is calculated automatically in your program, the maximum we get with the sensor is around 2,6 seconds. However, we need a maximum exposure time of 10 seconds. Before, by modifying the update_tegra_controls() and set_sen_exposure() functions in your programs, I could get a value of over 2,6 seconds. But with the new version, another function is called:
max_exposure

Should I modify this function now to achieve an exposure time of more than 2,6 seconds ?

3. L4T 35.x
The previous two points are problems I encountered when trying to install a 32.x version of L4T.
But I also tried a 35.x version. After seeing issue #49 I tried to follow the same steps.
For the pixelformat, I was able to obtain the GREY format as desired (by doing the method of the issue #52). Then, I ran the max_speed.sh script. But when I try to take an image, it still doesn't work, and I get a "NULL VI channel received" message in the dmesg. I read online that it was probably linked to a problem with the pix_clk_hz. Do you have an idea of how I can check that all the values are set correctly?

@bazo80
Copy link
Collaborator

bazo80 commented Feb 29, 2024

Hello @PierrickIntom ,

with latest version of the driver you mean the release 0.16.0 on the master branch in combination with L4T35.3.1?
I'm trying to reconstruct your use case.

@PierrickIntom
Copy link
Author

Hello @bazo80,
For the first two points, I was using the release 0.16.0 on the master branch in combination with L4T32.7.3.
For the third point, it was also the release 0.16.0, but this time with L4T35.3.1.

@bazo80
Copy link
Collaborator

bazo80 commented Mar 4, 2024

Hello @PierrickIntom ,

according to your third point:
I modified my device-tree like in the file attached
grey_y10_y12_dtsi.txt
With these settings I've got the three modes GREY, Y10 and Y12. But I could not reproduce the "NULL VI channel received" message.
I could reproduce it when setting the pix_clk_hz value to 800000000 like in the older L4T versions (32.7.3 and before)
My setup was an Auvidea JNX30D, IMX183 (Rev 15) and a Xavier NX running on L4T35.3.1 with driver release 0.16.0. The calls I used are in the following file:
grey_y10_y12.txt
Did you copy your old dtsi file into the release 0.16.0 and missed the switch of the pix_clk_hz setting between the old and the new Linux versions? Just an idea.
I also kept the line_length at 0 and the calculated line_length in the v4l2-ctl --all output was 5440 for 8 Bit and 10880 for 10/12Bit respectively.
For checking the values you have set you could look into the /proc filesystem:

cat /proc/device-tree/i2c@3180000/vc_mipi@1a/mode0/pixel_t
cat /proc/device-tree/i2c@3180000/vc_mipi@1a/mode0/pix_clk_hz

best regards

@PierrickIntom
Copy link
Author

Hello @bazo80,

Thanks for your help. I flashed the Xavier again, using the same dtsi file as you (but only with mode0, I only need grey 8 bit, not 10 and 12). dtsi.txt

After flashing I tried to follow the same calls as you. (I saw in the meanwhile that I flashed the release 0.17.0 instead of the 0.16.0, is this okay to compare ? Please tell me if I should flash the release 0.16.0) So I first ran sudo ./max_speed.sh -m. And then tried to acquire an image. But once again I got this NULL VI channel received problem.

Here are the calls and the dmesg for the initialization:
calls_dmesg.txt

And here a screenshot of the error:
dmesg_after_v4lcall

The calculated line_length in the v4l2-ctl --all output was 5440, so that's not a problem anymore.
The only difference I saw between your test and mine is the revision of the sensor, mine is older (0012 and you have revision 0015). Could this cause the problem ?

@PierrickIntom
Copy link
Author

I made more tests today, changing some things in the hardware and device tree:

  • I changed the sensor to have one with a more recent revision, so now I am using an IMX183 with revision 0014

  • Then, I saw that in the 0.12.3 version, we were using 4 lanes (set by default in the devicetree, and now by default to 2 lanes). So I updated the devicetree of the 0.17.0 version to have 4 lanes. But it didn't solve the issue:
    4lanes

  • I tried switching the sensor from the CD CSI port to the AB port. But then the pixel format wasn't recognize anymore, even though in the device tree I have exactly the same values for AB and CD.
    dmesg_sensorCD_port

Here is the complete device tree I used:
dtsi.txt

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants