search

chili-chips-ba / openeye-CamSI

A truly opensource camera serial interface. No frills. No backdoors that compromise security. Outstanding signal integrity. Hi-rez video pipeline with remote connectivity. For Sony, Series7 & open FPGA makers on limited budget. Augments openXC7 CI/CD, challenging its timing-savvy. Promotes the lesser-known EU boards.
https://nlnet.nl/project/TISG
BSD 3-Clause "New" or "Revised" License
25 stars 5 forks source link

issue#1 #12

Closed Juninho99 closed 5 months ago

Juninho99 commented 5 months ago

Fix I2C reset issue

First Issue:

The i2c_reset signal, which is generated in the top/u_clkrst_gen module, is based on the srst signal from the top/u_clkrst_gen/u_pll_top module. Since the srst signal does not occur at the very beginning, the i2c_reset signal is also delayed, as shown in the attached image. The image illustrates that as a consequence, i2c_sda and i2c_scl start, but then halt due to the reset.

The solution would be to ensure that i2c_reset is initially set to 0 and remains 0 until the rst_delay_cnt counter reaches 4 (since the I2C is enabled only after 4 seconds from the system power-up).

Second Issue:

When the reset signal in the top/u_i2c module goes to 0, data transmission on the I2C bus begins. However, at that moment, the value of the slave address, which is the first data transmitted via I2C, is set to an undefined value. Consequently, the setting of the slave_address_plus_rw (slave address plus read/write) signal is delayed by one data transmission cycle via I2C, which is not desirable. As a result, the first slave address written is 0.

To solve this second problem, the slave address should be set before the start of the I2C section. One approach is to introduce an additional input signal (which can be cam_en, as it occurs before the i2c_reset, as shown in the image).

image

Juninho99 commented 5 months ago

Changes in the branch issue#1 have resolved the first part of the problem, i.e. the I2C section no longer starts before the srst signal. This was achieved by inverting the logic of the i2c_reset. Simulation results confirm that this part is now resolved.

However, there remains an issue highlighted in the image: the first sent slave address is 0. This is further illustrated in the second image, where it is evident that the second register has the correct slave_address.

image

image

Juninho99 commented 5 months ago

The issue of the first slave address being 0 has been resolved by setting slave_address as the parameter I2C_SLAVE_ADDR in the top/u_i2c module, ensuring it is defined from the start. The solution is evident from the image below.

image