DS90UB954-Q1: ESD Inmunity Issues

Hello Carlos,

Please try the following:

• Set PAR_ERR_THOLD_HI to FF and set PAR_ERR_THOLD_LO to FF.  If that does not work, disable RX_PARITY_CHECKER_EN.
• Monitor the voltage rails during the ESD zap.  If they move outside the allowed VDD range, add filter caps.

Hello Hamzeh, 

Thanks for your reply. 

We have increased the PAR_ERR_THOLD to 0xFFFF, but we are still getting flicker on the image. Also, we have been monitoring the RX_PORT_STS1 (0x4D) for PARITY_ERROR and LOCK_STS_CHG status, once the flickers are happening there is no change on these bits! However we have a change (increase) in the AEQ_STATUS (0xD3) value in each ESD impact. 

Since we have no Lock/Pass change and no parity error, which event would trigger the AEQ to change the channel? 

Also, is there any status register that we can monitor for the Power supply OV/UV issues during the ESD impact? 

Cheers, 

Behnam

Hello Behnam,

for making AEQ more robust against ESD, can you write in Reg 0x42[6:4] = 000 before testing for ESD and see the behaviour?

Also you may try setting Reg 0x7C[5]=0 and test.

Hello Hamzeh, 

We have tried, disabling these two registers, and It works with ESD, but we thought is a bit cheat, to disable these two registers, of course is very helpful to check that we have an issue with the integrity of the FPDLink channel. 

Maybe is useful to work with this register 0x42:

[6] FPD-Link III clock errors
[5] Packet encoding errors
[4] Parity errors

And check which of these Error Control is being triggered. 

In the last tests with these bits disabled, the behaviour is much better....is not easy to appreciate it, sometimes when we discharge the gun, the video reduce the FPS it looks...., but no artifacts, 

Thanks for your feedback.

Hello Carlos,

of course it is not good idea to keep all three bits in reg 0x42 deactivated. That was just for testing purposes.

 It looks like, from the behavior described by you, that the image sensor is missing some frames during the ESD pulse, or the 954 is dropping these frames due to Parity errors.

 You can try write 0 to Reg 0x7C[5], so that the DES will not discard Frames at Parity errors.

Thanks Hamzeh,

We are trying to identify this....

To clarify...

[6] FPD-Link III clock errors - FPD Link related
[5] Packet encoding errors - FPD Link related
[4] Parity errors - Video From Imager 

Could you confirm my assumptions?

I would like to ask you one more question, since the 954 is a quite complex device, together with the 953, and there are a lot of registers which you should take in account, do you something like pre-defined state machine to manage these? Or any especial reference?

Thanks and regards!!

Hello Carlos,

No, all three types of errors are FPD-Link related errors. But the Parity error is more related to the content of the packet. Parity errors are caused by irregular changes to data, as it is recorded when it is entered in memory. So, these errors only have to do with the link between the SER and DES, which means they are independent of CSI errors.

Thanks Hamzeh,

Somehow then we need to improve the integrity of the FPDLink channel, since it seems we are somehow "manipulating/destroying" the signal. 

Please, could you also give us feedback about this:

I would like to ask you one more question, since the 954 is a quite complex device, together with the 953, and there are a lot of registers which you should take in account, do you something like pre-defined state machine to manage these? Or any especial reference?

Thanks!!

Carlos,

I could not get the idea behined your question about the state machine. Can you tell me what are you looking for specifically?

Hi Hamzeh,

Yes, as you know there are a lot of Error Registers, Interruptions which you can enable, and sometimes to create a state machine (SW) from scratch is bit difficult, so I am asking if you have some recommendations, guidelines in order to manage all of this diagnostics.

Thanks an regards!

Hello Carlos,

 Unfortunately we do not have a special code or state machine to check all error registers. This is something used in a custom way differently by different customers upon their needs.

 So you need to check which type of error you are want to check and then decide if this shall be periodically or only after each start-up or after any Lock-Unlock occasion.

 FYI, in the following App Note you have a good overview and description of all kind of error registers and interrupt functions. Also in the data sheet you can find some example code for programming these.

 https://www.ti.com/lit/an/snla267a/snla267a.pdf?&ts=1589212732935