DS90UB953A-Q1: Issue with CSI-2 errors when streaming is not started immediately

Hello,

Thank you for reaching out and providing such clear details here. It is possible that the serializer has entered a bad-state or has become stuck somewhere in the MIPI protocol. The serializer is designed to expect a continuous MIPI CSI stream, so starting/stopping or seeing non-protocol signals on the CSI lanes can occasionally cause the device to misidentify signals as data.  If the errors are continuous (preventing the stream entirely instead of a one off error logged), a soft reset can be issued to clear the internal blocks using register 0x01 = 0x01. Can you try this register write and see if the system recovers? If this does not work, can you share the overall sequencing of your system (ex: deserializer powered first, serializer powered second, deserializer configured, etc.) and any relevant delays? Is it correct that the imager is being reset and reconfigured after it has been operating and streaming properly to the serializer and deserializer?

Darrah, 

We are already performing the 0x01 = 0x01 soft reset about 20-30ms prior to toggling the standby/streaming bit on the camera, so this alone does not appear to solve our problem - however, it definitely is better than nothing, and previously we tried 200-300ms soft_reset<>streaming_start delay and had more CSI issues, so directionally it does appear that shrinking this gap is better.  Perhaps we could try starting imager streaming prior to the serializer soft reset?  Could there be any new issues with that?  Any other ideas?

Our bringup sequence is approximately as follows: 
-Deserializer powers up and comes out of reset, we enable the POC voltage rail
-V_POC comes up for the camera, which turns on the 3v3 regulator, which turns on our 1v8 regulator once 3v3 is PGOOD 
-20ms after 1v8 is >1.65V, we release PDB on the serializer, then configure its registers some time later after lock is established
-~60s later we use the serializer GPIO to bring the imager out of power down and then reset in accordance with its spec 
-~10ms after reset we write the imager configuration registers, but do not begin streaming 
-Some time after the imager config completes, we perform the 0x01 = 0x01 soft reset 
-20-30ms after the soft reset, we write the imager streaming bit = true and the imager begins streaming
-Vast majority of cameras work at this point, but some end up with the CSI errors previously discussed

"Is it correct that the imager is being reset and reconfigured after it has been operating and streaming properly to the serializer and deserializer?"
^ I am not sure what this means.  We reset and reconfigure the imager during the camera bringup sequence every time we boot, and this problem occurs after that process has occurred, but before we are successfully able to stream from the camera in question.  In general, we don't reset or reconfigure these cameras after they begin streaming properly/successfully (until power-down).  Can you clarify?  

Hello,

Yes, can you add a 0x01 = 0x01 write after the camera starts streaming and the errors are being seen? Assuming that the issue is the serializer going into a bad/stuck state due to unexpected signals on the CSI lanes, we don't know exactly when these signals are being seen. 

The question about the reset was meant to clarify if by "reset" you meant the camera powering up out of reset, or if this was a true reset and reconfiguration. Some systems do reset the camera in the middle of operation. However, for your case the reset and configuration is the initial configuration after power up.

We will try doing the 0x01 soft reset after beginning camera streaming and report back on what happens. 

Darrah - 

We have not yet tried the soft-reset-after-streaming-start, but now have reason to believe that the EMI/noise theory might not explain this issue. 

Below is an image of a scope capture of CSI2 on one of the failed units.  Yellow = I2C SDA, blue = CSI D0P, magenta = CSI D0N.  Our scope is not fast enough to accurately capture this signal, but we can see that something is clearly wrong by comparison.  

For comparison, here is an image of a working serializer with the same instrumentation below.  As you can see, we see continuous CSI activity in the working case, and the blue trace mostly mirrors the behavior of the magenta trace.  


Electrically, I'm unable to find any differences between the failed and working units.  The CSI2 lines on the failed unit are not shorted or disconnected, and their termination resistance when powered down appears similar across working/broken serializers (120-250kohm). 


Is there any chance that this rings a bell for a different issue or problem?  This seems potentially different than noise causing errors prior to streaming starting, since after streaming begins, the physical signals don't even appear to be sensible.  

Hello Davis,

The team is currently out of office due to the US public holiday and will resume activity on 9/3. Thank you for your patience during this time 

Best Regards,

Casey 

Were both of these scope shots taken at the same point in the power up sequencing? Is the I2C transaction seen on the SDA line on the far left of the scope shot the start streaming command for the camera? The serializer is only a CSI receiver and is not able to prevent or stop a continuous CSI steam coming from the camera. Does the camera report any errors? It looks like there is some activity on the SDA line during the start/end of the CSI activity.

Can you provide a register dump of the serializer for both of these cases?

These scope shots were taken at relatively (but not exactly) the same time.  The large I2C transaction you see on the far left is the same in both instances, this is the mode table being written.  

In both the good and bad cases you see a bit of I2C activity right before CSI starts, this is us setting the streaming bit on the imager. In the bad case our program attempts to stop streaming after the errors occur / no valid stream appears, clear errors and then start over again, but this fails over and over. 

I am not aware of the imager reporting any errors, but I will see if we can check.  For what it's worth, it's the same imager in both cases, just a swapped serializer board - and the good serializer works every time, bad serializer fails every time. 

I will also ask our SW team if it's possible to get a full register dump from the serializer.