VCID using 2 cameras with GMSL MAX9286

Autonomous Machines Jetson & Embedded Systems Jetson TX2
1

Hi all,

We are using the Astro Carrier board from Connect Tech which has a MAX9286 deserializer with 4 camera inputs.

We already have the driver for our serializer (MAX96705) and sensor (OV10635) working for all the inputs independently, and all the inputs are using different Virtual Channel IDs. Which means the VCID configuration at DTB level is properly configured.

Now, we are trying to enable simultaneous capture from 2 cameras. Both cameras are configured, however when we try to capture from 2 cameras we got nothing.

Then we identified the problem is related to the MAX9286, because we are not using any frame synchronization mechanism yet. After that we proceed disabling the frame sync in the MAX9286 deserializer and we got the following:

  1. TX2 starts receiving frames, but the SHORT_FRAME error appears in the trace.
  2. MAX9286 deserializer triggers a Line Buffer Overflow error (register 0x22), which means the internal line buffer queue is being filled and overflowed.

Based on all of this, I have a couple of questions:

  1. Do you know if the Line Buffer Overflow error might be affecting the frame size and causing the SHORT_FRAME error?
  2. If so, do you think Frame Sync is completely necessary to allow capture from both cameras in the deserializer?
2
  1. It’s better to confirm with vendor.
  2. I don’t think frame sync is necessary.
3

Hi Carlos,

I’ve seen cases where SHOT_FRAME or other errors appear in the trace log but are not the root cause of the issue. When we were first moving to R31 for the original Xavier L4T pre-release I had this sort of problem. To debug it I looked at ph_wc (packet header word count) and pf_crc (packet format crc) registers for NVCSI (see the TRM). I found that the word count wasn’t matching and also crc errors. Eventually we traced the root cause to a clocking issue. As you know clocks are handled more stringently on R31+. In R31 the clocks were set based on pix_clk_hz but if you had a serdes system the pixel clock of the image sensor doesn’t necessarily have much to do with the pixel clock of the NVCSI port. This problem is why serdes_pix_clk_hz was added to R32.

Regards,
Greg

4

Hi Greg,

We have tested serdes_pix_clk_hz without success. Setting it to a higher value than pix_clk_hz didn’t help, that’s why we think this is a problem at the MAX9286 deserializer side, caused by the frame sync issue.