Closed wuyuanyi135 closed 1 year ago
Hello @wuyuanyi135 ,
Are you using an Espressif board, such as the ESP32-S3-EYE or your own custom board? I don't have the ov5640 camera here to test in the same conditions, I did test the I2C changes on an ESP32-S3 and a simpler device (GPIO expander with read/write/write-read, all worked)
I see from your config that you are using I2C Port 1. How are you configuring/initializing it? What frequency are you using? Internal or external pull-ups?
I see that the camera could be detected. Do you have a logic analyzer to check what is going on the bus during an I2C read?
Hi @o-marshmallow
It's my own board designed for a product. I used i2c port 1 with 400khz frequency and external pull-ups. I bisected the commit log and discovered the above-mentioned commit caused the issue.
I also had a i2c gpio expander (AW9523) on the same bus and it worked properly. It's the camera probe on SCCB bus that caused the issue.
Afaik, the esp32-camera uses the i2c periph for the SCCB protocol. I am not sure if they were using some low-level functions to emulate the protocol, which causes the invalid operations after this commit?
Sorry, I don't have a logic analyzer at this moment. Can you test the espressif board with camera? I think any DVP camera like ov2640 should reproduce the issue
Hi @wuyuanyi135 ,
Thanks for the info! I was able to get an ESP32-S3-EYE on my end which is equipped with an OV2640 camera, I tested it with the esp_camera
example from ESP-BSP (https://github.com/espressif/esp-bsp/tree/master/examples/display_camera) and it worked successfully on my end, even with the latest IDF master, which includes the I2C SDA timing fix. I tested several time to make sure it's stable and yes it is.
Here is the output I got:
I (505) cam_hal: cam init ok
I (515) camera: Detected camera at address=0x30
I (515) camera: Detected OV2640 camera
I (515) camera: Camera PID=0x26 VER=0x42 MIDL=0x7f MIDH=0xa2
I (565) s3 ll_cam: node_size: 3072, nodes_per_line: 1, lines_per_node: 16
[...]
In my opinion, the problem is a timing issue, so it may be related to the transition delays. In fact, the fix I pushed lets the I2C hardware component module sample the SDA level at the middle of the high-period of SCL line.
Before the fix, the SDA sample timing had an invalid value which was larger than the SCL high-period duration. Thus, I suspect that SDA sampling was triggered at the end of the high-period, so the transition SDA line from low to high had more time that now. (twice more time)
To verify the hypothesis, can you try reducing the frequency a bit until you reach a one that is stable enough to communicate with the camera? (370KHz? 350KHz?)
Also, most importantly, which value did you choosing for your pull-up resistors?
@o-marshmallow Thanks for your clear explanation about how the fix works. If I understand correctly, the SDA was sampled at a time point that was later than when it should have sampled. It was working for me because of high line capacitance, so when sampled the value was correct, as if the frequency was a bit lower. After the fix was applied, because the sampling occurs eariler, the value SDA was not still on the rising edge, causing invalid sample?
I am using 2.2K Ohms pullups to 3.3V for both lines. There are three slave devices on the bus: AW9523 (3pF), INA219 (6pF), OV5640 (10pF). The board was about 7cm so I don't really think the frequency would cause the trouble. But I will give it a try to reduce the frequency.
@wuyuanyi135 This is my hypothesis yes. Now we need to verify it. In fact, 2.2KOhm pull-ups sounds good for 400KHz and your capacitance, that is also the value used on the ESP32-S3-EYE's pull-ups.
Ideally having an oscilloscope would help a lot to see the slope of SDA and SCL lines going high and low.
Reducing the frequency would give more time to the slaves to set SDA line. Another trick to modify the SDA sample time would be to use I2C1.sda_sample.sda_sample_time += n
. Of course this is just a workaround to debug the problem, not a solution. You could try lowering resistor values too, but that's slower to put in place that the previous software tricks.
In the latest manufacturered unit the issue is gone. Probably electronic issue in my previous board. Though not sure if there has been some change to the I2C component since the issue. Close for now.
@wuyuanyi135 Good to hear! No changes from our side on the I2C so far, may be a hardware issue indeed.
Answers checklist.
IDF version.
3bc3f8720974da676192569e885867095f3808fd (fauty)
Operating System used.
Windows
How did you build your project?
Command line with Make
If you are using Windows, please specify command line type.
PowerShell
Development Kit.
ESP32-S3-WROOM-1-N16R2
Power Supply used.
USB
What is the expected behavior?
commit before 3bc3f8720974da676192569e885867095f3808fd did not cause the error:
What is the actual behavior?
after commit 3bc3f8720974da676192569e885867095f3808fd
Steps to reproduce.
Debug Logs.
No response
More Information.
Camera configuration: