ESP32 + OV7670 camera: need assistance

[code4sex]

Hi,
I'm struggling with OV7670 camera and still can't get proper images out of it...
I want to get a 256x256 monochrome pixel region. Camera operates in YUV422 mode so I'm aimed at a higher 8-bits part of the 16-bit output. With that said, I'm having the following:

- all pads configured as pulled-up inputs; VSYNC inverted, interrupt attached.
- clocking @ 20MHz or 40MHz via LEDC
- D0...D7 MUXed to appropriate I2S signalling
- camera module is missing HREF pad so I'm using HSYNC instead
- windowing consigured as per datasheet (HSTART, VSTART, HSTOP, VSTOP, HREF)
- test grayscale mode activated
- I2S has the following capturing config:
-- I2S0.conf.rx_right_first = 0;
-- I2S0.conf.rx_msb_right = 0;
-- I2S0.fifo_conf.rx_fifo_mod = 1;
Hence I expect to get the byte flow: CAMERA = s1, s2, s3, s4, ... FIFO = 00 s1 00 s2, 00 s3 00 s4, ... (shown in many source files on github).

FIFO/DMA configured to fill the temporary junkBuffer with 4096 words (16834 bytes). Later on I pick up the luma bytes from there.

RESULTS:

(a) the junkBuffer reads this (the first 32 bytes are shown per frame):

Code: Select all

54 00 54 00 86 00 86 00 54 00 54 00 86 00 86 00 54 00 54 00 86 00 86 00 54 00 54 00 86 00 86 00
A5 00 A5 00 9D 00 9D 00 A5 00 A5 00 9D 00 9D 00 A5 00 A5 00 9D 00 9D 00 A5 00 A5 00 9D 00 9D 00
B6 00 B6 00 B2 00 B2 00 B6 00 B6 00 B2 00 B2 00 B6 00 B6 00 B2 00 B2 00 B6 00 B6 00 B2 00 B2 00
A0 00 A0 00 A0 00 A0 00 A0 00 A0 00 A0 00 A0 00 A0 00 A0 00 A0 00 A0 00 A0 00 A0 00 A0 00 A0 00
86 00 86 00 54 00 54 00 86 00 86 00 54 00 54 00 86 00 86 00 54 00 54 00 86 00 86 00 52 00 52 00

The "XX 00 YY 00" pattern differs from expected "00 XX 00 YY"

(2) I ran 4 different scenarios and picked up every N-th byte (0...3) from the junkBuffer and got the following images:

a01.jpg (110.57 KiB) Viewed 27080 times

Once (on a very rare occasion) I happened to get a more or less structured pattern:

a02.jpg (28.77 KiB) Viewed 27080 times

(3) The picures above were generated by the camera with a terrible 20cm wiring. In hope to cut off the possible noise I reassembled the design replacing signal wires with a thick short soldered pins wrapped in isolator. VCC/GND/SDA/SCL/RESET and PWDN are left untouched.

a03.jpg (118.1 KiB) Viewed 27080 times

Such a modification did not yield any positive result however

[code4sex]

(4) LIGHT sensitivity
With grayscale test mode turned off the camera senses the amount of light and outputs lighter or darker images. The image on the left was made in the ambient light. After I hit a sensor with a direct LED-flashlight the camera gave significantly lighter images.

a04.jpg (138.97 KiB) Viewed 27079 times

(5) WINDOWING

Datasheet says the actual signalling area is 784x510 pseudopixels whereas the active area is limited to 640x480.
So I tried setting up 256x256 window using both methods:

a05.jpg (42.68 KiB) Viewed 27079 times

With no luck.


Finally, I turned windowing off and tried to fill the incoming array of pixels as 640x113 image. Again, garbage only.

a06.jpg (34.68 KiB) Viewed 27079 times

* * *

Q: Any suggestions as to what may be wrong with the whole thing? Or maybe there's someone already solved such a problem?

[code4sex]

PS. A short notice on h/w - here are some snapshots from the scope.

Windowing ON/OFF comparision:

Those are two screenshots merged in one and matched against VSYNC mark: yellow signal = VSYNC, cyan signal = HSYNC (HREF)
One may see the windowing work as expected. Also, VSYNC is low when HSYNC/HREF is high, so appropriate signal inversion is made other esp32 side:

Code: Select all

gpio_matrix_in(config->pin_vsync, I2S0I_V_SYNC_IDX, 1); // 1 = INVERT SIGNAL

a07.jpg (315.26 KiB) Viewed 27022 times

PCLK line:

a08.jpg (83.03 KiB) Viewed 27022 times

So the h/w is operating alright if that might matter anyone....

[inverse2k1]

hi,

two observations:
your line impedance might still be completely mismatched.

But, by the looks of it, the camera configuration registers seem to be completely off track.
It's like the pixel format and maybe the frame format are different from what you expect.
Also, knowing the device does not encode in jpeg format, the frame buffer configuration might be wrong as well.