CX3: CyU3PMipicsiSetSensorControl() fails error 0x4A (CY_U3P_ERROR_FAILURE)

[ErDE_3356256]

Hello Infineon Experts,

We use a CX3 and one or two related image sensors on our board, and we are facing a CY_U3P_ERROR_FAILURE value returned by the CyU3PMipicsiSetSensorControl() API. This behavior is random, but the error rate is over 20 %.

We probed the I2C bus and some other significant signals (CX3_RESET*, CX3_XRESET and CX3_XSHUTDOWN), to look what’s happen (see attached pictures):

• On successful execution, a first reading of Register 0x0012 (CY_U3P_MIPICSI_REG_GPIOIN) is done, bits [2:1] of this value are set to ‘1’ to drive High XRESET and XSHUTDOWN pins, the changed value is written to Register 0x0014 (CX3_CSI_SENSOR_SIG_VAL) and a second reading of Register 0x0012 is performed to be sure that Register 0x0014 is correctly written. So, reserved bits of Register 0x0014 are preserved as requested to section 1.10.7 of CX3 TRM.
• On fail execution, the second reading of register 0x0012 doesn’t match the writing to Register 0x0014 and the CyU3PMipicsiSetSensorControl() API returns CY_U3P_ERROR_FAILURE. The difference concerns the reserved bit 0.

Do you have an explanation for this error CY_U3P_ERROR_FAILURE?

For your information, both SDA and SCL signals are pulled high with 2kΩ resistors, and the I2C block is initialized (by calling CyU3PMipicsiInitializeI2c() API) before initializing the MIPI-CSI-2 block (i.e. before calling CyU3PMipicsiInit() API).

Best Regards,

Eric.

[Rashi_Vatsa · Accepted solution]

Hello Eric,

Your understanding is correct. The reason of this error CY_U3P_ERROR_FAILURE in CyU3PMipicsiSetSensorControl API  is when register read and register write values do not match.

Please confirm the following:

- I2C line SCL & SDA are pulled up to VDDIO1. Please let me know the voltage level of VDDIO1

- Is there any other (except Cx3) I2C master connected to the I2C lines

- Is there any other I2C slave connected to the I2C bus with similar slave address

- Please let me know if the firmware can be tested on CX3 Reference Design - Denebola kit. 

Please refer to this thread with similar issue Solved: CX3: AppInit:MipicsiInit Err = 0x4A - Cypress Developer Community 

[ErDE_3356256]

Hello Rashi,

Thank you for your reply. Here are my answers to your questions:

“I2C line SCL & SDA are pulled up to VDDIO1. Please let me know the voltage level of VDDIO1”

=> Yes, both lines are pulled up to VDDIO1 = 1.8 V.

“Is there any other (except Cx3) I2C master connected to the I2C lines”

=> No, CX3 is the only I2C Master.

“Is there any other I2C slave connected to the I2C bus with similar slave address

=> No, the image sensors have the following addresses: 7’b0010000 and 7’b0110110.

“Please let me know if the firmware can be tested on CX3 Reference Design - Denebola kit.”

=> Our firmware cannot be tested directly on Denebola kit. But we are testing a ‘light’ version of this firmware to focus on the MIPI Block configuration. Under these conditions, if the issue is easy to reproduce, we will test it on our Denebola kits and of course inform you of the result.

Regards,

Eric

[Rashi_Vatsa]

Hello Eric,

Please refer to this thread for the commonly used I2C pull up resistor values Solved: CX3, i2c , 2-bytes address, 2-bytes data - Cypress Developer Community 

You can try using pull up resistors of these values

[ErDE_3356256]

Hello Rashi,

I read the thread you pointed out, but in our case, I think we are facing an issue around the MIPI block. Indeed, the image sensors are in their reset state until the Register 0x0014 is written by calling the CyU3PMipicsiSetSensorControl() API.

Concerning the pull up resistors, I checked their value on our PCBA: 2.2 kΩ instead of 2 kΩ mentioned in my first message.

I checked also the VDDIO1 power supply during Register 0x0014 writing and Register 0x0012 reading (see attached screenshots): 1.793 V (Avg.) and 7.78 mV (Pk-Pk) Max. I performed these measurements with an SMA hand-formable cable (0.086 diameter) soldered on one side as close as possible to the decoupling caps of the 2 VDDIO1 pins, and connected on the other with an SMA-BNC adapter to a passive probe fitted with its BNC adapter. In this way, no ground lead could corrupt our measurements. Our oscilloscope has 12-bit ADCs.

As announced in my first message, we tested a ‘light’ firmware (i.e. by cycling the 24 Vdc power supply input of our board): no CY_U3P_ERROR_FAILURE after 452 cycles (2.5 s On/120 s Off), but more tests must be done before drawing a conclusion.

However, could you tell us more about the reserved bits 0 of Registers 0x0014 and 0x0012? Are they exclusively reserved for the MIPI block? Could their logical state depend on another CX3 block? Wouldn't it be necessary to add a delay between writing register 14 and reading register 12?

Regards,

Eric.

[Rashi_Vatsa]

Hello Eric,

Thank you for update.

As announced in my first message, we tested a ‘light’ firmware (i.e. by cycling the 24 Vdc power supply input of our board): no CY_U3P_ERROR_FAILURE after 452 cycles (2.5 s On/120 s Off), but more tests must be done before drawing a conclusion

>> Please let me know on which board are you testing the firmware and what is the difference between the board where CY_U3P_ERROR_FAILURE is seen

 Are they exclusively reserved for the MIPI block? Could their logical state depend on another CX3 block?

>> The bits are reserved for CX3 MIPI block and it doesn't seem t o have any dependence on other CX3 blocks

 Wouldn't it be necessary to add a delay between writing register 14 and reading register 12?

>> Please refer to the implementation of CyU3PMipicsiSetSensorControl API which adds delay of 5 ms between the write and read

[ErDE_3356256]

Hello Rashi,

Please find my answers:

Please let me know on which board are you testing the firmware and what is the difference between the board where CY_U3P_ERROR_FAILURE is seen

>> All the firmware tests carried out have been done with our board, until right now. On this board, you have a dc-dc converter (24V to 5V) which supplies another dc-dc converter and some LDOs. The CX3's power-up and power-down sequences are compliant with this thread: CX3-Power-up-Power-down-Sequencing.

>> The firmware where CY_U3P_ERROR_FAILURE is seen has an official Revision in our Version Control System, and the firmware that doesn't is a light version, as you can see in the attached screenshot.

I in turn would like to ask you questions:

• We call the CyU3PMipicsiSetSensorControl() API to deactivate XRESET and XSHUTDOWN, and from that perspective the job is done. What risk would we run if CY_U3P_ERROR_FAILURE were simply ignored?
• Why a delay of 5 ms between the write and read in your CyU3PMipicsiSetSensorControl() API?
• Is it because a CX3 state machine needs it?

Regards,

Eric.

[Rashi_Vatsa]

Hello Eric,

We call the CyU3PMipicsiSetSensorControl() API to deactivate XRESET and XSHUTDOWN, and from that perspective the job is done. What risk would we run if CY_U3P_ERROR_FAILURE were simply ignored?

>> We recommend not to ignore the error

Why a delay of 5 ms between the write and read in your CyU3PMipicsiSetSensorControl() API?Is it because a CX3 state machine needs it?

>> The delay between write and read API is to provide enough time to the CX3 MIPI block to update the read register.

The firmware where CY_U3P_ERROR_FAILURE is seen has an official Revision in our Version Control System, and the firmware that doesn't is a light version, as you can see in the attached screenshot.

>> Is the API failing every time (for every call) when official revision of the firmware is used and never fails when light version is used?

As you are testing on the same board we are not able to narrow down the problem. If the firmware (official version) works on development kit like Denebola, we can know that the problem is related to hardware.

We have tested calling the API on Denebola kit multiple times and it doesn't fail.

[ErDE_3356256]

Hello Rashi,

Thank you for your answers, here are mine:

We recommend not to ignore the error

>> These last days we implemented a workaround, which consists in making up 5 initializing attempts of MIPI Block before reporting an error to the driver which in return send a Reset Request to the CX3. 15 API calls can be made before declaring our product out of order.

The delay between write and read API is to provide enough time to the CX3 MIPI block to update the read register.

>> 5 ms, it’s a long update. Did you know its tolerance?

Is the API failing every time (for every call) when official revision of the firmware is used and never fails when light version is used?

>> On our board, the error rate is over 20% with the official revision of the firmware, and 0% with its light version.

As you are testing on the same board we are not able to narrow down the problem. If the firmware (official version) works on development kit like Denebola, we can know that the problem is related to hardware.

We have tested calling the API on Denebola kit multiple times and it doesn't fail.

>> I would not be as categorical as you are because the PCBAs are different: they do not have the same power supply domains, the same I2C pull-ups (2.2 kΩ for our board, 10 kΩ + I2C Bus buffers for Denebola kit), and the same power-up/power-down sequencing. Remember this thread, the Denebola kit was not so clean about power-up and power-down sequencing.

Now, we will change the Denebola kit options to have the same power supply domains and the same I2C pull-ups as our board. We will let you know the result.

Regards,

Eric.

[Rashi_Vatsa]

Hello Eric,

15 API calls can be made before declaring our product out of order.

>> I understand that after 15 CyU3PMipicsiSetSensorControl API calls the API fails. Is that correct?

5 ms, it’s a long update. Did you know its tolerance?

>> Most of the API used for reading and writing to MIPI block uses the 5ms delay. I didn't understand the question. Can you please elaborate?

 On our board, the error rate is over 20% with the official revision of the firmware, and 0% with its light version.

>> Please let me know how many times the API is called in official version and light version. And is the API called back to back in both the version. I am asking this to know the difference between the versions.

I would not be as categorical as you are because the PCBAs are different: they do not have the same power supply domains, the same I2C pull-ups (2.2 kΩ for our board, 10 kΩ + I2C Bus buffers for Denebola kit), and the same power-up/power-down sequencing. Remember this thread, the Denebola kit was not so clean about power-up and power-down sequencing.

>> I understand. As mentioned in the thread, we have not seen failures on Denebola kit. I will also try calling the API (>15 times) back to back on Denebola kit and let you know the results

[ErDE_3356256]

Hello Rashi,

I understand that after 15 CyU3PMipicsiSetSensorControl API calls the API fails. Is that correct?

>> In fact, if an error (CY_U3P_ERROR_FAILURE) is still present after 15 attempts (5 MIPI Block Init x 3), we declare on host side our product out of service.

Most of the API used for reading and writing to MIPI block uses the 5ms delay. I didn't understand the question. Can you please elaborate?

>> I was just amazed that it takes several milliseconds between writing and reading, while the system clock is several hundred megahertz.

Please let me know how many times the API is called in official version and light version. And is the API called back to back in both the version. I am asking this to know the difference between the versions.

Prior to implementing our workaround, both the official and light versions made only one API call. The attached screenshot is the code that implements our workaround.

Regards,

Eric.

[Rashi_Vatsa]

Hello Eric,

Please find my comments

 I was just amazed that it takes several milliseconds between writing and reading, while the system clock is several hundred megahertz.

>> This is because the register read and written is different. The delay allows the other register to update and then read

Prior to implementing our workaround, both the official and light versions made only one API call. The attached screenshot is the code that implements our workaround

>> Please explain the reason for workaround. Is this the only instance where MIPI related APIs are called in the official and light versions? If no, please share the flow in which the MIPI related API are called in firmware.

If possible , share the firmware. This will help to reproduce the issue.

I tried to port the code snippet in the default OV5640 cx3 example firmware but didn't see the error. (results attached)

Please let me know the reason for calling mipicsireset before mipicsiinit. MIPI init internally calls mipicsireset

[ErDE_3356256]

Hello Rashi,

I'm sorry for my late reply, but my company has moved. Here are my answers:

Please explain the reason for workaround.

>>Prior to workaround, when MIPI block initialization was performed without CY_U3P_ERROR_FAILURE, the next step was to initialize the sensors via the same I2C bus than MIPI Block. On the other hand, when a CY_U3P_ERROR_FAILURE occurred, the initialization of the sensors was not done and our driver on the host side was not informed. Thus the sensors were not operational, and more seriously our application was not informed because this error was not processed.

>>After you recommended us not to ignore the CY_U3P_ERROR_FAILURE, we decided to implement workaround described earlier in February the 5^th. And we did well because we saw up to 5 consecutive errors occurred (see attached screenshot) before the sixth succeeded.

Is this the only instance where MIPI related APIs are called in the official and light versions? If no, please share the flow in which the MIPI related API are called in firmware.

>>Yes, this is the only instance because during this period of time ThreadX OS is in single task mode.

If possible, share the firmware. This will help to reproduce the issue.

>>Unfortunately, it’s not possible to share the firmware.

Please let me know the reason for calling mipicsireset before mipicsiinit. MIPI init internally calls mipicsireset.

>>You are right, it is superabundant but at the beginning of our investigations we wanted to be sure to reset the MIPI block.

Regards,

Eric.

[Rashi_Vatsa]

Hello Eric,

Prior to workaround, when MIPI block initialization was performed without CY_U3P_ERROR_FAILURE, the next step was to initialize the sensors via the same I2C bus than MIPI Block. On the other hand, when a CY_U3P_ERROR_FAILURE occurred, the initialization of the sensors was not done and our driver on the host side was not informed.

>> From this I understand that earlier when the sensor was not configured using I2C bus of CX3, the API never failed. Is my understanding correct?

If yes, is it possible to disconnect the sensor and check if the API still fails?

Please let me know if there are other I2C slaves connected to CX3 I2C bus.

Also, let me know how different is the CX3 MIPI receiver and sensor initialization flow of the custom firmware as compared to the firmware generated by the tool as per this KBA Steps to Setup up MIPI CSI Camera Solution with CX... - Cypress Developer Community