CX3 MIPI-GPIF-DMA flow not working

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

Hi,

   

[0] I am trying to get the CX3 to work with our own mipi camera ( RAW 8 bit 4224x3136 pixels (432 Hblank and 6236 Vblank), 108 mhz clock (so 216Mhz bit rate), 4 lanes, 2.2 fps), currently using an Econ Denebola baseboard.

   

I have used the eclipse tool to generate a configuration for that and merged the results with the Denebola demo code and the Cx3UvcOV5640 code present in the Cypress SDK.

   

Unfortunately so far the DMA callback function is not called.

   

Things I checked:
- If i use the camera with the exact same settings as i am using now on the devboard accompanying the camera it works (so camera is outputting something useful over the MIPI bus). Also verified the mipi bus with scope and all seems ok.

   

- If i enable the CyCx3AppMipiErrorThread to print the results of the CyU3PMipicsiGetErrors function i get all 0's. But if we short eg a data line the error counters go up. So i am pretty sure the MIPI block thinks it is (somewhat) working. It would be useful to have a better indication of this though.

   

- I also print the CyU3PMipicsiQueryIntfParams result params in the loop, these always are what i configured them to be

   

- If i do a CyU3PGpifGetSMState in the CyCx3AppMipiErrorThread loop, it prints that the GPIF is in state 2 all the time. Looking at cyu3mipicsi.h this corresponds to #define CX3_WAIT_FOR_FRAME_START_SCK0           2, so it seems the GPIF block never got going.

   

- If i use CyU3PDmaMultiChannelGetStatus i get state 2 (CY_U3P_DMA_ACTIVE) for both sockets 0 and 1 and prodXferCount = consXferCount = 0. If i check the contents of the DMA buffers then nothing changes in there (but if GPIF is not working as detected in the previous step then this is logical).

   


So first guess is that there is something going wrong between MIPI bus and GPIF block. Is there anything else  i can check to get a better idea what is going on there ?

   

Related questions:
[1] To put the gpif in pauze mode there seem to be 2 different functions
Generated code (by exclipse tool):

   

    /* Start the state machine. */
    status = CyU3PGpifSMStart (CX3_START_SCK0, ALPHA_CX3_START_SCK0);
        ...

   

    /* Pause the GPIF interface*/
    CyU3PGpifDisable(CyFalse);

   


Refcode:
      /* Start the state machine. */
    status = CyU3PGpifSMStart (CX3_START_SCK0, ALPHA_CX3_START_SCK0);
        ...
    /* Pause the GPIF interface*/
    CyU3PGpifSMControl(CyTrue);

   


    /* Resume the Fixed Function GPIF State machine */
    CyU3PGpifSMControl(CyFalse);

   


Is the generated code correct ? Because after the disable there is no more "start", but maybe the CyU3PGpifSMSwitch function will also reenable the gpif ? ?

   


[2] In the CX3 TRM it is stated
"Packing more than one pixel per PCLK is possible. For example, selecting the “MIPI CSI input -Data format"
configured as "RAW8" and the  “MIPI interface configuration  –  data format”  as a 24bit  format  (RGB888)  will
output  three pixel  data  per PCLK.  Similarly,  two 10 bit or 12bit pixels can be packed and output per PCLK
using the 24 bit output format."

   

But i cannot find anywhere how I can do this ?

   


[3] The TRM only documetns a few of the MIPI i2c accessible registers.
Can i find documentation somewhere regarding:
#define CY_U3P_MIPICSI_REG_GPIOEN   (0x0E)

   

#define CY_U3P_MIPICSI_REG_GPIOIN   (0x12)

   

#define CY_U3P_MIPICSI_REG_PHYCLKCTL   (0x56)
#define CY_U3P_MIPICSI_REG_PHYDAT0CTL  (0x58)
#define CY_U3P_MIPICSI_REG_PHYDAT1CTL  (0x5A)
#define CY_U3P_MIPICSI_REG_PHYDAT2CTL  (0x5C)
#define CY_U3P_MIPICSI_REG_PHYDAT3CTL  (0x5E)

   

#define CY_U3P_MIPICSI_REG_PHY_STAT    (0x62)
#define CY_U3P_MIPICSI_REG_CSI_STAT    (0x64)
#define CY_U3P_MIPICSI_REG_CSI_ERR_EN  (0x66)
#define CY_U3P_MIPICSI_REG_MDLSYN_ERR  (0x68)
#define CY_U3P_MIPICSI_REG_CSI_DID     (0x6A)
#define CY_U3P_MIPICSI_REG_CSI_DID_ERR (0x6C)
#define CY_U3P_MIPICSI_REG_CSI_PKTLEN  (0x6E)
#define CY_U3P_MIPICSI_REG_CSIRX_DPCTL (0x70)
#define CY_U3P_MIPICSI_REG_FRM_ERR_CNT (0x80)
#define CY_U3P_MIPICSI_REG_CRC_ERR_CNT (0x82)
#define CY_U3P_MIPICSI_REG_COR_ERR_CNT (0x84)
#define CY_U3P_MIPICSI_REG_HDR_ERR_CNT (0x86)
#define CY_U3P_MIPICSI_REG_EID_ERR_CNT (0x88)
#define CY_U3P_MIPICSI_REG_CTL_ERR_CNT (0x8A)
#define CY_U3P_MIPICSI_REG_SOT_ERR_CNT (0x8C)
#define CY_U3P_MIPICSI_REG_SYN_ERR_CNT (0x8E)

   

#define CY_U3P_MIPICSI_REG_MDL_ERR_CNT (0x90)
#define CY_U3P_MIPICSI_REG_FIFO_STAT   (0xF8)

   

Thanks!

7 Replies
Anonymous
Not applicable

Small update: After comparing the MIPI bus communication of the working OV5640 sensor with that of our AR1335 sensor we saw the following 2 differences:

   

 

   

[1] clock keeps running for the AR1335, for the OV5640 the clock is only active during line data

   

[2] OV5640 generates short packets for start and end of line, the AR1335 does not seem capable of doing this

   

Is the CX3 MIPI block able to deal with the continuous clock and the lack of start/end of line packets ?

0 Likes
Anonymous
Not applicable

Had the same issue with continuous and non-continous MIPI clock, for my sensor there was the possibility top change the clock mode. Missing start and end of line packages should be no issue.

   

CX3 is configured for a non-continous clock mode by default. But there is a workaround form Cypress to use the continous clock mode.

   

CX3 chip recognizes CSI clock by MIPI CSI LP --> HS mode transition at the beginning.

   

So after finishing initialization of CX3 MIPI bridge, CSI clock must transit from LP to HS mode. You have to follow the following sequence in firmware, if you are using the sensor in “continuous clock mode”.

   

a) Upon receiving the Set_Cur (Commit control) request from the host, perform a MIPI reset (CyU3PMipicsiReset() with reset type as Hard reset )

   

b) Initialize the MIPI bridge (CyU3PMipicsiInit () )

   

c) Set the MIPI interface parameters (CyU3PMipicsiSetIntfParams ())

   

d) Release reset of the sensor(XRST). (CyU3PMipicsiSetSensorControl() )

   

 e) Configure the sensor

0 Likes
Anonymous
Not applicable

Wow , thanks a lot !

   

Meanwhile i have found a bit to set our sensor in non-continuous mode too ( nothing for line/start end but that may not be an issue then) but now the data on the MIPI bus suddenly has other problems (no more ths zero time for some reason no matter how big i configure this, and unfortunately no support from the camera vendor to explain this)  so the MIPI block is reporting errors all over the place.

   

So if the workaround for continuous mode works that would be great (in continuous mode the MIPI  data coming from the sensor is ok).

   

Thanks again !

   

 

   

Note to forum mods: For some reason if i post the above message but insert the word 'correctly' between round brackets at the ... in the sentence:

   

the MIPI block is ... reporting errors

   

I get a

   

"Access Denied
You don't have permission to access "http://www.cypress.com/comment/reply/527136" on this server.

   

Reference #18.99991002.1489057507.1e33a8a8"

0 Likes
Anonymous
Not applicable

After implementing the workaround i now also get errors being reported by the MIPI block in continuous mode, not sure if i should consider this an improvement (because the mipi block is seeing something) or a step backwards (because it is only seeing errors ).

   

Now i am not sure the errors are caused by still troubles in the mipi block with the continuous clock mode or the lack of line begin/start, or because the MIPI data on the bus is not according to the MIPI configuration. I would expect the data itself to be fine (at least in continuous clock mode) because it works when i connect the camera with the same parameters to a different receiver.

   

Example of error counts:

   

errCnts.crcErrCnt 27,errCnts.ctlErrCnt 0, errCnts.eidErrCnt 34, errCnts.frmErrCnt 10, errCnts.mdlErrCnt 255, errCnts.recSyncErrCnt 255, errCnts.recrErrCnt 87, errCnts.unrSyncErrCnt 255 , errCnts.unrcErrCnt 121

   

Sometimes when i restart it is only the errCnts.mdlErrCnt , errCnts.recSyncErrCnt and errCnts.unrSyncErrCnt that go to 255 and the rest remains zero, no idea what causes the difference.

   

I do have a question/remark about the workaround though

   

If in step a) you do a CyU3PMipicsiReset with as type hard reset, then if you check the SDK code the variable 'glMipiBlockInitialized' will be set to true at the end, and doing a CyU3PMipicsiInit () in step b) has not effect at all because it checks that variable and returns immediately if initialization was already done 

   

(at least this is the case in SDK 1.3.3)

0 Likes
Keerthy_V
Moderator
Moderator
Moderator
First like given 250 sign-ins 50 solutions authored

Hi,

   

 

   

What all are the MIPI errors that you are getting when the sensor is configured for gated clock? 

   

Did you configure the MIPI bridge properly in this case? Can you please attach the screenshot of your MIPI configuration tool window?

   

Did you try varying the THSsettle parameter using the API CyU3PMipicsiSetPhyTimeDelay(). Are there any variation in the number of errors after changing the THSsettle parameter?

   

 

   

Regards,

   

Keerthy

0 Likes
Anonymous
Not applicable

Hi Keerthy,

   

Because i did not seemed to get any more responses here I created a support case for this and you already helped me there last week (but i still added a few follow up questions).

   

The conclusion was that it was indeed the THSSettle parameter that was out of spec.

   

Thanks again,

   

Bram

0 Likes

O!

You are very good engineers.

We even couldn’t start the same sensor ov5640 as on Denebola, on our custom board.

It seems that the same reason - the signal is not read by MIPI.

Those, he is, but the CX3 does not recognize it.

0 Likes