Tool/software:
Good day.
Our configuration.
DS90UB954 to which two DS90UB953 are connected
Connection via coaxial cable with power supply via it.
An IMX412 camera is connected to each DS90UB953.
The CSI output from the DS90UB954 is connected to the Jetson Orin Nano module.
Two CSI lines are used
Image capture is performed via gstreamer
We launch both channels.
gst-launch-1.0 nvarguscamerasrc sensor-id=0 ! 'video/x-raw(memory:NVMM), width=(int)1920,height=(int)1080,framerate=30/1' ! nvvidconv flip-method=0 ! 'video/x-raw, format=(string)I420' ! xvimagesink -e --verbose | gst-launch-1.0 nvarguscamerasrc sensor-id=1 ! 'video/x-raw(memory:NVMM), width=(int)1920,height=(int)1080,framerate=30/1' ! nvvidconv flip-method=0 ! 'video/x-raw, format=(string)I420' ! xvimagesink -e –verbose
After that, everything works.
Moreover, it can work for 6-18 hours without errors.
Then a failure can occur, in which the image begins to twitch, something like an echo is obtained.
We investigated the problem by reading the DS90UB954 status registers.
RX_PORT_STS2 (Address 0x4E) returns the value 0x14
Which indicates the error BUFFER_ERROR bit 4
It can also be RX_PORT_STS2 (Address 0x4E) = 0x1C -> CSI_ERROR
Questions:
Please tell me what could be the cause of the buffer overflow?
Is it possible to reset this overflow through the registers?
Hello Ivan,
The buffer overflows when the data cannot be transmitted into the CSI output port faster than it is being received. So, it indicates an issue of aggregating the too much data from the multiple sensors or the received line length is larger than the buffer can store.
The DS90UB954-Q1 has a 16kb line buffer (FIFO) per port, so normally it could support this format, as long as the average rate of video lines coming in is slow enough to ensure that the line buffer won't overfill on the DES which also depends on the configured CSI-2 output rate (which would determine the FIFO drain rate) and the CSI-2 lane rate/line timing on the CSI-2 input side (which would determine the FIFO fill rate).
To be able to calculate exactly we will require the following details:
What is the data type or number of bits per pixel coming from the imager?
What is the used CSI output lane speed?
Are you using synchronized forwarding or Round Robin forwarding on the DES?
What is the value of the REFCLK connected to the DES?
Is your SER running on back-channel Synch mode, or using and external Oscillator? of external, what is the value?
Hello Hamzeh Jaradat.
Thank you very much for your reply.
I will now answer your questions.
What is the data type or number of bits per pixel coming from the imager?
We are using RAW10 (10, bits) data type.
What is the used CSI output lane speed?
We use a maximum speed of 1.6 Gbps and 2 data lanes.
Are you using synchronized forwarding or Round Robin forwarding on the DES?
Using synchronous mode
What is the value of the REFCLK connected to the DES?
We use a 25 MHz quartz oscillator
Is your SER running on back-channel Synch mode, or using and external Oscillator? of external, what is the value?
Using backchannel synchronization
Our IMX412 sensor uses clocking from an external 24 MHz crystal oscillator
Regularities in buffer overflow.
Video capture can run for 4 hours or 18 hours without failing.
HI Ivan,
As I said, this could be a bandwidth issue or a unstable incoming resolution.
Can you please provide the resolution and frame rate from each camera? I just realized that it is not provided.
I can calculate the input and output data rate/band width at the DES and see if this is somehow related.
Hello, thank you for your reply.
an you please provide the resolution and frame rate from each camera? I
The frame rate is 30 fps for both channels.
Resolution 1920x1080 also on both channels
Hi Ivan,
resolution and data rate look fine and should not cause any buffer error.
Do you see any other error?
Can you provide registers dump from the SER and DES, for good case and for failure case?
Good day.
Reading registers is done as follows.
At first, we read all DS90UB954 registers and two DS90UB953 channels.
Read registers via I2C.
If the value in the register is not zero, we write it to the log.
Then we perform a cyclic reading of the registers and compare the current value with the one read earlier.
If the value read from the register has changed, we output it to the log.
I am attaching a log in which there is no error ds90-log.txt.
String format.
[00:28:10.390] 954-:DEVICE_STS [0x04]=0xDF
[00:28:10.390] - current time
954 - reading DS90UB954 register
DEVICE_STS - register name
[0x04] - register address
0xDF - read value
For DS90UB953 registers the format is slightly different
[00:28:10.395] 953-:GENERAL_STATUS [0x52]=0x45:0x45
[00:28:10.390] - current time
953 - reading DS90UB953 register
GENERAL_STATUS - register name
[0x52] - register address
0x45:0x45 - read value channel 0: channel1
Since we read two channels DS90UB953 then at the end two values of the read registers
In the file error-ds90-log.txt there are errors with buffer overflow.
When the error occurred, we tried to do Digital Reset 0 in the registers:
DS90UB954 -> Reset[0x01]:DIGITAL_RESET0 = 1
DS90UB953[0,1]->RESET_CTL[0x01]: DIGITAL_RESET_0 = 1
This does not solve our problem.
Tell me if it is possible to somehow reset the buffer without restarting the image capture.
[00:28:10.390] 954-:DEVICE_STS [0x04]=0xDF [00:28:10.390] 954-:PAR_ERR_THOLD_HI [0x05]=0x01 [00:28:10.390] 954-:RX_PORT_STS1 [0x4D]=0x43 [00:28:10.391] 954-:RX_PORT_STS2 [0x4E]=0x14 [00:28:10.392] 954-:LINK_ERROR_COUNT [0xB9]=0x33 [00:28:10.392] 954-:CSI_STS [0x35]=0x01 [00:28:10.393] 954-:CSI_TX_ISR [0x37]=0x03 [00:28:10.394] 953-:DEVICE_ID [0x00]=0x32:0x32 [00:28:10.395] 953-:GENERAL_STATUS [0x52]=0x45:0x45
Hi Ivan,
when error happens and then disappear and comes back again, are you doing anything on your setup to make it come/go away?
Have you tested a different UB954 board? Do you see same issue?
If you disconnect one camera and keep only one, will you see the issue?
Do you know what is the lane speed the imager sensor is transmitting the CSI data into the SER? Is there any way to reduce this speed down? Because the data format you are transmitting should only require around 350Mbps/lane. What I think it happening here is that the sensor is sending the whole frame very quickly with minimal LP11 time between lines and then sitting idle for a long period of time before the next frame. Instead, it would be better to reduce the vertical blanking by slowing down the line rate while still maintaining the same pixels and frame rate. The 954 is also configured to output 800Mbps/lane, but the DPHY timing parameters are probably slightly slower on the 954-side compared to what the sensor is outputting which is leading to an offset in how quickly 954 can send the lines vs. how quickly they are coming in over multiple lines in a frame. That is causing a buffer overflow.
when error happens and then disappear and comes back again, are you doing anything on your setup to make it come/go away?
No, we don't do anything after the error appears, you need to either restart the video capture or reboot.
Have you tested a different UB954 board? Do you see same issue?
We have the same problem with another board.
If you disconnect one camera and keep only one, will you see the issue?
We didn't test long enough with one camera, but we never saw any problems.
Do you know what is the lane speed the imager sensor is transmitting the CSI data into the SER? Is there any way to reduce this speed down?
We can't say anything about the transmission speed of our sensor yet.
We are studying the issue of reducing the speed.
In this case, our sensor transmits a stream on 2 lines of RAW10 bits with a resolution of 1920x1080 30 frames.
We cannot say what the real speed of the CSI - CER is.
Is it possible to determine this by reading the DS90UB953 registers?
The 954 is also configured to output 800Mbps/lane
Our line speed is 1600 Mbps.
We tried to make the speed 800 but got a buffer overflow effect when turned on.
It would be nice to be able to reset the buffer during work.
So you understand that this is not possible?
Is it possible to determine this by reading the DS90UB953 registers?
No, it is not possible to determine the lane speed from SER register reads.
It would be nice to be able to reset the buffer during work.
So you understand that this is not possible?
Correct. You can not reset the buffer.
As I said, I think it is an imager/SER lane speed issue. Please try to reduce the lane speed and check the blanking length on the imager sensor