• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 6 answers
  • Subscribers 35 subscribers
  • Views 681 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DS90UB954-Q1: the synchronization setting

Yusuke Mukuno
Expert 7395 points
Part Number: DS90UB954-Q1


Hi Expert,

Using 2 inputs of ds90ub954-q1,
Customer would like to set RX0 and RX1 to port forward and implement 2 virtual channel inputs to the SOC.
【conditions】
  ・ 2 inputs
  -Raw 8 bit (YUV422 format) DT code 0x1E
  ・ Use RX0 as VC0 and RX1 as VC1
  ・ Use Basic synchronous input.
  ・ Use with 2Lane setting
 
How should they set for the synchronization settings as above conditions?

Please refer the synchronization setting values as below,

* <0x10 0x93>, // FrameSync signal; Device Status; Enabled
* <0x58 0x5E>
* <0x19 0x0A>, // FS_HIGH_TIME_1
* <0x1A 0xD7>, // FS_HIGH_TIME_0
* <0x1B 0x61>, // FS_LOW_TIME_1
* <0x1C 0xA0>, // FS_LOW_TIME_0
* <0x18 0x01>, // Enable FrameSync
* <0x21 0x14>, // Basic　Sync

<0x20 0x00>, // forwarding of all RX to CSI0
<0x7c 0xc8>, // use lower 8bit, discard short frame
<0x6d 0x7b>, // STP, discard 1st line on err
<0x0c 0xdf>, // LED pass #1, lock #1, enable #1
<0x58 0x58>, //        I2C pass through
<0x5c 0xb0>, // alias 58
<0x5d 0x90>, // slave 0 id 48
<0x65 0x90>, // slave 0 alias 48
<0x5e 0x91>, // slave 1 id 49
<0x66 0x91>; // slave 1 alias 49

Current issue

The data cannot be taken on the CSI input side, and video is not output.

Thanks

Muk

  • 0
    TI__Mastermind 30515 points

    Muk,

    1. could you pls check if the lock pin is stable? you can check reg. 0x4c (select channel 0 or channel 1), reg. 0x4d, 0x4e, 0x55, 0x56, 0x73/74/75/76?, what is the status of these registers?

    2. If above registers are right based on d/s function description, pls check reg. 0x21. You can check the reg. description in ub954 d/s page84 to select the correct sync. mode. also, please set reg. 0x1F/0x33 to select the correct CSI2 data rate, lane number and CLK continuous output mode.

    3. pls measure UB954's CSI2 clock output is it correct?

    best regards,

    Steven

  • 0 in reply to Steven(Shenzhen) Shi
    TI__Expert 7395 points

    Hi Steven-san,

    I got the customer feed back for your questions as below,

    Could you please check it?

    I read the status register, but it is not an abnormal value.
    But there is no video at the later SOC.

    【Reading when the product does not operate in the synchronous setting】
    [Tue Nov 19 09:26:21.032 2019] [    1.446628]  dtcam RX0 reg read 0x4d [13]
    [Tue Nov 19 09:26:21.032 2019] [    1.452366]
    [Tue Nov 19 09:26:21.032 2019] [    1.452366]  dtcam RX0 reg read 0x4e [45]
    [Tue Nov 19 09:26:21.066 2019] [    1.458091]
    [Tue Nov 19 09:26:21.066 2019] [    1.458091]  dtcam RX0 reg read 0x55 [00]
    [Tue Nov 19 09:26:21.066 2019] [    1.463819]
    [Tue Nov 19 09:26:21.066 2019] [    1.463819]  dtcam RX0 reg read 0x56 [00]
    [Tue Nov 19 09:26:21.066 2019] [    1.469542]
    [Tue Nov 19 09:26:21.066 2019] [    1.469542]  dtcam RX0 reg read 0x73 [02]
    [Tue Nov 19 09:26:21.066 2019] [    1.475269]
    [Tue Nov 19 09:26:21.066 2019] [    1.475269]  dtcam RX0 reg read 0x74 [5d]
    [Tue Nov 19 09:26:21.066 2019] [    1.480991]
    [Tue Nov 19 09:26:21.066 2019] [    1.480991]  dtcam RX0 reg read 0x75 [00]
    [Tue Nov 19 09:26:21.066 2019] [    1.486717]
    [Tue Nov 19 09:26:21.066 2019] [    1.486717]  dtcam RX0 reg read 0x76 [00]
    [Tue Nov 19 09:26:21.094 2019] [    1.492521]
    [Tue Nov 19 09:26:21.094 2019] [    1.492521]  dtcam RX1 reg read 0x4d [53]
    [Tue Nov 19 09:26:21.094 2019] [    1.498251]
    [Tue Nov 19 09:26:21.094 2019] [    1.498251]  dtcam RX1 reg read 0x4e [c5]
    [Tue Nov 19 09:26:21.094 2019] [    1.503976]
    [Tue Nov 19 09:26:21.094 2019] [    1.503976]  dtcam RX1 reg read 0x55 [00]
    [Tue Nov 19 09:26:21.094 2019] [    1.509700]
    [Tue Nov 19 09:26:21.094 2019] [    1.509700]  dtcam RX1 reg read 0x56 [00]
    [Tue Nov 19 09:26:21.094 2019] [    1.515423]
    [Tue Nov 19 09:26:21.094 2019] [    1.515423]  dtcam RX1 reg read 0x73 [00]
    [Tue Nov 19 09:26:21.116 2019] [    1.521146]
    [Tue Nov 19 09:26:21.116 2019] [    1.521146]  dtcam RX1 reg read 0x74 [52]
    [Tue Nov 19 09:26:21.116 2019] [    1.526869]
    [Tue Nov 19 09:26:21.116 2019] [    1.526869]  dtcam RX1 reg read 0x75 [51]
    [Tue Nov 19 09:26:21.116 2019] [    1.532594]
    [Tue Nov 19 09:26:21.116 2019] [    1.532594]  dtcam RX1 reg read 0x76 [7c]

    The default value (Do not write to the 0x 21 register) of the async setting 0 x 21 works
    In addition, both inputs are input to the SOC side without any problem, and the image is output at the SOC side.
    However, if it is asynchronous, the LineCount of the video output of Video1 and Video2 on the Soc side does not match.
    The value increases over time. This is why it is intended to work with synchronization settings.

    Initial value of running asynchronously changed to running synchronously with sync 0x21
    If a register is written in the following pattern, it cannot be received at the SOC side of the subsequent stage.
    SOC expects the data to come in the following form.


    [Frame format that can be received at the SOC]
    |-------------------------------------------------------?
    |                      Blanking                         |
    |                                                       |
    |-------------------------------------------------------|
    | |FS|                       |                          |
    |  ￣                        |   Frame 1 (Field 1)      |
    |Line Blanking               |   Odd frame No1          |
    |←ーーーーーーーーーーーー→|                          |
    |                            |                          |
    |                            |                          |
    |--------------------------- |--------------------------|
    | |FE|                                                  |
    | ￣￣                                                  |
    |                      Blanking                         |
    |-------------------------------------------------------|
    | |FS|                       |                          |
    |  ￣                        |   Frame 2 (Field 2)      |
    |Line Blanking               |   Eaven frame No2        |
    |←ーーーーーーーーーーーー→|                          |
    |                            |                          |
    |                            |                          |
    |--------------------------- |--------------------------|
    | |FE|                                                  |
    | ￣￣                                                  |
    |                      Blanking                         |
    |-------------------------------------------------------?


    Basic synchronization settings you tried (Frame is not detected at all on the SOC side of the subsequent stage and does not operate.)
    ★Adding to try synchronization settings. If there is no ★, it operates as an asynchronous setting.

                               <0x1f 0x02>, // 800MHz　
                               <0x4C 0x01>, // RX0
     ★                        <0x6E 0xAA>, // BC_GPIO_CTL0: FrameSync signal to GPIO0/1
                               <0x72 0xE4>, // Map Sensor A VC0 to CSI-Tx VC0
                               <0x70 0x1e>, // vc0 + 1e(=ycbcr422)
                               <0x7c 0xc8>, // use lower 8bit, discard short frame
     
                               <0x4C 0x12>, // RX1
     ★                      　<0x6E 0xAA>, // BC_GPIO_CTL0: FrameSync signal to GPIO0/1
                               <0x72 0xE4>, // Map Sensor B VC0 to CSI-Tx VC1
                               <0x70 0x5e>, // vc1 + 1e(=ycbcr422)
                               <0x7c 0xc8>, // use lower 8bit, discard short frame
     
     
     
     ★                        <0x10 0x93>, // FrameSync signal; Device Status; Enabled
     ★　　　　　　　<0x58 0x5E>
     ★                        <0x19 0x0A>, // FS_HIGH_TIME_1
     ★                        <0x1A 0xD7>, // FS_HIGH_TIME_0
     ★                        <0x1B 0x61>, // FS_LOW_TIME_1
     ★                        <0x1C 0xA0>, // FS_LOW_TIME_0
     ★                        <0x18 0x01>, // Enable FrameSync
     ★★★                    <0x21 0x14>, // Basic　Sync
     
       　　　　　　　<0x33　0x21> // 2Lane設定
                               <0x20 0x00>, // forwarding of all RX to CSI0
                               <0x20 0x00>, // forwarding of all RX to CSI0
                               <0x7c 0xc8>, // use lower 8bit, discard short frame
                               <0x6d 0x7b>, // STP, discard 1st line on err
                               <0x0c 0xdf>, // LED pass #1, lock #1, enable #1
                               <0x58 0x58>, //        I2C pass through
                               <0x5c 0xb0>, // alias 58
                               <0x5d 0x90>, // slave 0 id 48
                               <0x65 0x90>, // slave 0 alias 48
                               <0x5e 0x91>, // slave 1 id 49
                               <0x66 0x91>; // slave 1 alias 49
     
    ★is the setting you tried with the sync settings (Basic).
     Please confirm.
     Please let me know if there is a setting error.
     
     
    I changed the sync settings only in "★ ★ ★" and tried the following cases.
    I will let you know the result.
     

    TI's 0x 10 register 21: Synchronous forwarding with line interleaving
    ------------------
    ■ Value: If it is 0xC9, the picture comes out, but the data is not correctly received in pink and green X
    ■ Value: The image comes out in the case of 0 x 89. One side only. X
    ■ Value: In case of 0xd9, the picture comes out, but the data is not correctly received in pink and green X
    ■ Value: The image comes out in the case of 0 x 49. One side only. ×

    TI's 0 x 21 register Basic synchronization
    - - - - -
    ■ Value: No video at 0 x 15.
    ■ Value: No video at 0 x 45.
    ■ Values: 0 x 85 has only one side.
    ■ Value: If it is 0xd5, the picture comes out, but the data cannot be received correctly in pink, green, pink and green X.


    I am sorry to trouble you, but could you tell me how to set up the synchronization of the decile so that Video 1 and Video 2 can be synchronized on the SOC side in the latter stage?

    Thanks

    Muk

  • 0 in reply to Yusuke Mukuno
    TI__Mastermind 30515 points

    Muk,

    1. When you read reg. 0x4d/4e etc., do you set the correct reg. 0x4c to select channel 0 or channel1? from the reading result, it has link issue, you can check reg. 0x4d/4e, also reg. 0x73/74/7576 indicates the line size and line number are not correct. Please check the link jitter margin design (why the link is unlocked?) and try to check if the async. mode is ok or not? also, you check one by one channel, if it is correct? I concern maybe the camera design also has issue, so this issue would be messed up with your sync. issue.

    2. In your attached frame format required by SoC, it is not matched with our frame sync. output format. you can check d/s page48 "Figure 31. Basic Synchronized Format", here it is on basic sync. mode, please make sure that the sync. mode can be aligned with the SoC's CSI2 input requirement.

    3. when reg. 0x21 is set as 0xd5, it means the CSI0 is set as aync. mode, is it right? also, can you check if the sync. signal is transmitted correctly in your system from ub954 to ub953? you can measure the GPIO signal which is used to transmit the frame sync.

    btw, what is your video resolution and color format?

    best regards,

    Steven

  • 0 in reply to Steven(Shenzhen) Shi
    TI__Expert 7395 points

    Hi Stven-san,

     

    Could you please give me your comment for the following customer comment?

     

     

    ・DS954 is used as a deserializer and DS953 is used as a serializer.

     

    ・resolution is 1280x960,　format is YUV422

     

    ・Tried 0xD5 Write to register 0x21.

    　 the picture comes out, but the data cannot be received correctly in pink, green, pink and green　.

     

    ・Is 0xd5（reg:0x21) an understanding of the correct setting　?

    　Is it OK to understand that there is a problem with the SOC setting,

    　and that there is no problem with the setting of the deshiri(DS954)?

     

    　I want to make it clear whether it is necessary to check the SOC settings.

    　Is it okay that there is no problem as a setting of deshiri?

    　Close if there is a problem on the SOC side

     

    　Please point out if there is a problem with the current settings．

     

     

    Thanks

    Muk

  • 0 in reply to Yusuke Mukuno
    TI__Mastermind 30515 points

    Muk,

    For UB954, it can support different CSI2 forwarding mode, such as RR (default, reg. 0x21[0]), Sync. (also has 3 kinds of sync. mode). Which mode is selected, it is dependent on your system design, such as SOC's CSI2 decoding request, system sync. request, etc.

    please below function description on reg. 0x21, do you need the csi replicate mode or not (reg. 0x21[7])? also pleas note: Only one of CSI0_RR_FWD and CSI0_SYNC_FWD must be enabled at a time. if you set reg. 0x21 as 0xd5, it is NOT correct. If you need replicate & basic sync. mode, you need set reg. 0x21 as 0x90.

    0x21 FWD_CTL2          
        7 CSI_REPLICATE RW 0 CSI Replicate Mode
     When set to a 1, the CSI output from port 0 will also be generated on CSI port 1.  In this mode, each CSI port may be one or two lanes only.
     The same output data will be presented on both ports.
        6 FWD_SYNC_AS_AVAIL RW 0 Synchronized Forwarding As Available
     During Synchronized Forwarding, each forwarding engine will wait for video data to be available from each enabled port, prior to sending the video line.  Setting this bit to a 1 will allow sending the next video line as it becomes available.  For example if RX Ports 0 and 1 are being forwarded, port 0 video line will be forwarded when it becomes available, rather than waiting until both ports 0 and ports 1 have video data available.  This operation may reduce the likelihood of buffer overflow errors in some conditions.  This bit will have no affect in video line concatenation mode and only affects video lines (long packets) rather than synchronization packets.
        5:4 reserved R 0 Reserved
        3:2 CSI0_SYNC_FWD RW 0 Enable synchronized forwarding for CSI output port 0
     00: Synchronized forwarding disabled
    01: Basic Synchronized forwarding enabled
    10: Synchronous forwarding with line interleaving
    11: Synchronous forwarding with line concatenation

    Only one of CSI0_RR_FWD and CSI0_SYNC_FWD must be enabled at a time.
        1 reserved R 0 Reserved
        0 CSI0_RR_FWD RW 1 Enable best-effort forwarding for CSI output port 0.
     When this mode is enabled, no attempt is made to synchronize the video traffic.  When multiple sources have data available to forward, the data will tend to be forwarded in a round-robin fashion.
     0: Round robin forwarding disabled
    1: Round robin forwarding enabled

    Only one of CSI0_RR_FWD and CSI0_SYNC_FWD must be enabled at a time.
  • 0 in reply to Steven(Shenzhen) Shi
    Prodigy 30 points
    Hi Stven-san,
    Here is my view.
    Could you please give me your comment.

    "0x 21 reg set is 0x 90" is an asynchronous mode setting, which works asynchronously.
     I have seen that the default 0x01 works fine when I checked it. Check if 0x 90 also works asynchronously.

    In asynchronous mode, when received on the SOC side, the line count of RX0 and RX1 will shift, so it is a proposition to operate in synchronous mode.


    I think it is correct to do it in Basic mode with FS_A, FS_B, FE_A and FE_B． (Same image as SOC.)
    In other cases, FS_A and FS_B are grouped together, so they don't match the SOC.

    In Basic, disable CSI_REPLICATE and check CSI0 _RR_FWD by setting it to 1.
    0x21 reg set is  0x15

    (5: 4: Reserve = 1,

    3: 2 CSI 0 _SYNC_FWD =01,

    0: Round robin forwarding enabled = 1)


    If it still does not work, is it correct to understand that there is a problem on the SOC side?

    Supplement
    0x90 did not appear on the back-end SOC.
    The packet monitor of the latter stage SOC when the image comes out at 0x01
    It is less than.
    0x90 is not shown below.

    Case where no video appears (reg 0x21 = 0x90)
    [16.367953] Packet header 0: dt: 0x00, vc: 0, wc: 0, cnt: 0
    [16.377188] Packet header 1: dt: 0x00, vc: 0, wc: 0, cnt: 0
    [16.386372] Packet header 2: dt: 0x00, vc: 0, wc: 0, cnt: 0
    [16.395521] Packet header 3: dt: 0x00, vc: 0, wc: 0, cnt: 0
    [16.404614] Packet header R 0 dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.414065] Packet header R 1 dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.423487] Packet header R 2 dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.432868] Packet header C 0: dt: 0x00, vc: 0, wc: 0, cal_parity: 0x00
    [16.443016] Packet header C 1: dt: 0x00, vc: 0, wc: 0, cal_parity: 0x00
    [16.453073] Packet header Monitor 1: dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.463169] Packet header Monitor 2: dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.473167] Packet header Monitor 3: dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.483086] Packet header Monitor 4: dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.492934] Packet header Monitor 5: dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.502726] Packet header Monitor 6: dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.512464] Packet header Monitor 7: dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.522176] Packet header Monitor 8: dt: 0x00, vc: 0, wc: 0, ecc: 0x00

    Cases where video appears (reg 0x21 = 0x01)
    [16.641730] Packet header 0: dt: 0x1e, vc: 0, wc: 2560, cnt: 1
    [16.704082] Packet header 1: dt: 0x1e, vc: 1, wc: 2560, cnt: 1
    [16.704087] Packet header 2: dt: 0x1e, vc: 0, wc: 2560, cnt: 1
    [16.704091] Packet header 3: dt: 0x1e, vc: 1, wc: 2560, cnt: 1
    [16.704095] Packet header R 0 dt: 0x1e, vc: 1, wc: 2560, ecc: 0x07
    [16.704098] Packet header R 1 dt: 0x1e, vc: 1, wc: 2560, ecc: 0x07
    [16.704102] Packet header R 2 dt: 0x1e, vc: 1, wc: 2560, ecc: 0x07
    [16.704106] Packet header C 0: dt: 0x1e, vc: 1, wc: 2560, cal_parity: 0x07
    [16.704110] Packet header C 1: dt: 0x1e, vc: 1, wc: 2560, cal_parity: 0x07
    [16.704114] Packet header Monitor 1: dt: 0x1e, vc: 0, wc: 2560, ecc: 0x11
    [16.704118] Packet header Monitor 2: dt: 0x1e, vc: 1, wc: 2560, ecc: 0x07
    [16.704122] Packet header Monitor 3: dt: 0x1e, vc: 0, wc: 2560, ecc: 0x11
    [16.704125] Packet header Monitor 4: dt: 0x1e, vc: 1, wc: 2560, ecc: 0x07
    [16.704129] Packet header Monitor 5: dt: 0x1e, vc: 0, wc: 2560, ecc: 0x11
    [16.704133] Packet header Monitor 6: dt: 0x1e, vc: 1, wc: 2560, ecc: 0x07
    [16.704136] Packet header Monitor 7: dt: 0x1e, vc: 0, wc: 2560, ecc: 0x11
    [16.704140] Packet header Monitor 8: dt: 0x1e, vc: 1, wc: 2560, ecc: 0x07

    case 0x21 reg is 0x15
     RX0 Pink and RX1 green both is sandstorm
    [   62.698748] Packet header 0: dt: 0x1e, vc: 1, wc: 2560, cnt: 1
    [   62.705412] Packet header 1: dt: 0x1e, vc: 1, wc: 2560, cnt: 1
    [   62.712015] Packet header 2: dt: 0x1e, vc: 1, wc: 2560, cnt: 1
    [   62.718637] Packet header 3: dt: 0x1e, vc: 1, wc: 2560, cnt: 1
    [   62.725259] Packet header R 0 dt: 0x1e, vc: 0, wc: 2560, ecc: 0x11
    [   62.732205] Packet header R 1 dt: 0x1e, vc: 0, wc: 2560, ecc: 0x11
    [   62.739189] Packet header R 2 dt: 0x1e, vc: 1, wc: 2560, ecc: 0x07
    [   62.746165] Packet header C 0: dt: 0x1e, vc: 0, wc: 2560, cal_parity: 0x11
    [   62.753840] Packet header C 1: dt: 0x1e, vc: 1, wc: 2560, cal_parity: 0x07
    [   62.761523] Packet header Monitor 1: dt: 0x1e, vc: 1, wc: 2560, ecc: 0x07
    [   62.769032] Packet header Monitor 2: dt: 0x1e, vc: 0, wc: 2560, ecc: 0x11
    [   62.775978] Packet header Monitor 3: dt: 0x1e, vc: 1, wc: 2560, ecc: 0x07
    [   62.782922] Packet header Monitor 4: dt: 0x1e, vc: 0, wc: 2560, ecc: 0x11
    [   62.789852] Packet header Monitor 5: dt: 0x1e, vc: 1, wc: 2560, ecc: 0x07
    [   62.796791] Packet header Monitor 6: dt: 0x1e, vc: 0, wc: 2560, ecc: 0x11
    [   62.803719] Packet header Monitor 7: dt: 0x1e, vc: 1, wc: 2560, ecc: 0x07
    [   62.810655] Packet header Monitor 8: dt: 0x1e, vc: 0, wc: 2560, ecc: 0x11
    [   62.836737] CRCECM: 357
    [   62.839256] LCNT0: 0x01710119

    (★★★RX0 0x171: RX1 0x119 mismatch★★★)

    best regards,

    Fumiyuki

  • 0 in reply to user6235376
    TI__Mastermind 30515 points

    Hi Fumiyuki,

    sorry I make a typo here, if you need replicate & basic sync. mode, you need set 0x21 as 8b'1000 0100 = 0x84.

    if reg.0x21 = 0x01 can work well, it means the FPD-Link transmission is ok, the key issue is on CSI2 forwarding problem which need be aligned between UB954 output and SoC's input. You can check d/s on sync. forwarding format and select the one which can be known by SoC? Thanks.

    best regards,

    Steven

  • 0 in reply to Steven(Shenzhen) Shi
    Prodigy 30 points

    Hi  Steven

    0x84 result
    [16.230701] Packet header 0: dt: 0x00, vc: 0, wc: 0, cnt: 0
    [16.240125] Packet header 1: dt: 0x00, vc: 0, wc: 0, cnt: 0
    [16.249559] Packet header 2: dt: 0x00, vc: 0, wc: 0, cnt: 0
    [16.258877] Packet header 3: dt: 0x00, vc: 0, wc: 0, cnt: 0
    [16.268134] Packet header R 0 dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.277727] Packet header R 1 dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.287236] Packet header R 2 dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.296697] Packet header C 0: dt: 0x00, vc: 0, wc: 0, cal_parity: 0x00
    [16.306907] Packet header C 1: dt: 0x00, vc: 0, wc: 0, cal_parity: 0x00
    [16.317036] Packet header Monitor 1: dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.327104] Packet header Monitor 2: dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.337109] Packet header Monitor 3: dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.347047] Packet header Monitor 4: dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.356909] Packet header Monitor 5: dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.366678] Packet header Monitor 6: dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.376497] Packet header Monitor 7: dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    [16.386090] Packet header Monitor 8: dt: 0x00, vc: 0, wc: 0, ecc: 0x00
    So the SOC side does not react.


    Enabling CSI0_RR_FWD and disabling CSI_REPLICATE will still result in a sandstorm, but it is recognized as a packet.
    There is a way to synchronize by detecting WC on the SOC side of the latter stage,
    It has not been confirmed whether the setting is correct.
    I will check the SOC side. In order to spend a little time, if there is no problem other than 0x21, close the question.
    If there is no problem with settings other than 0x21, close it once

    best regards,

    Fumiyuki

  • 0 in reply to user6235376
    TI__Mastermind 30515 points

    Hi Fumiyuki,

    sorry I can't decode the above message clearly. the "dt" data type is 0x00?

    [16.376497] Packet header Monitor 7: dt: 0x00, vc: 0, wc: 0, ecc: 0x00

    best regards,

    Steven

  • 0 in reply to Steven(Shenzhen) Shi
    Prodigy 30 points
    Hi Steven-san
    Thank you for confirmation.

    If the CSI2 packet is monitored on the SOC side during normal operation asynchronously, 0x1e is monitored for the DT code. (YUV422 Raw12)
    If set 0x21 reg set 0x84 ( in Basic mode), the DT code is not decoded and cannot be monitored, and the monitor default value of 0x00 is displayed.
    The SOC manufacturer is currently checking the SOC settings. Since it takes time to get an answer, if there are no other problems, close it once.
    best regards, Fumiyuki
  • 0 in reply to user6235376
    TI__Mastermind 30515 points

    Thank Fumiyuki for update.

    yes, it is right that the CSI2 transmission should be aligned between ub960 output (we can set it as different mode) and SoC.

    best regards,

    Steven