OV2640 JPEG mode image corruption

OpenMV Products
#1

Hi,

I am working on a personal project using the OV2640 camera module as well, and I am wondering whether someone here came across the problem described above or if someone has any ideas what the issue might be as I am stumped. I have a custom board with a STM32F407 MCU running a real time OS (ChibiOS) and using the DCMI interface to get the data from the camera as jpeg images. It works fine about 80% of the time, but 20% of the images I capture come out corrupted. See the attached image for how the corruption manifests - it seems like some data is missing or shifted from the jpeg file?

I’ve been playing with the OV2640 registers for a long time but I don’t seem to be able to solve the issue. I am using MC0 cl0ock output to clock the camera module at 8Mhz, PCLK is 12Mhz (changing PCLK does not seem to solve the problem). If I could just narrow down whether the problem is in the sensors itself (maybe the PLLs and clocks are not set correctly?), or with my code on the MCU, or with the hardware (PCB), that would be a big step already.

So does anyone have any ideas? I’m happy to post more info if required.

Regards,
-Igor

Pic4.jpg
Pic4.jpg1024×768 22.5 KB

#2

For those interested, I managed to solve the problem.

I derived the XCLK for the camera module through the MCO0 output fed by the HSI. The MCU was running of the SYSCLK derived from HSE through PLLs. It seems HSI and HSE clocks were not synchronized and somewhere when crossing clock domains (i assume either in the DCMI peripheral or when doing DCMI-memory DMA) this was causing synchronization issues as some data was not yet stable in both clock domains. I changed to using an HSE derived clock for camera XCLK hence having both the camera and the MCU in the same clock domain and I haven’t experienced the problem since.

Cheers,
-Igor

#3

Good you found the problem. I had no clue! :slight_smile:

#4

When I designed the CMUcam4. I did some crazy stuff to get 30 FPS operation on the Propeller Chip. I actually had an NCO counter from the prop set to 1/2 the system clock frequency (96 MHz - so 48 MHz). I then used the NCO output to clock the camera. I turned of the camera’s PLL and then sent the PCLK output from the camera back to the prop.

This clocking structure insured both chips were in lock step. This allowed me to use an loop of assembly instructions to read the image data bus as it was coming in off the camera without having to have the one of the propeller chip’s core synchronize to each external PCLK pulse. All I had to do was wait for the rising HSYNC signal, time delay, and then start reading the i/o pins into RAM as fast as possible.

That was some crazy code.

#5

Hey Igor,

I don’t think that’s the issue, I actually used the MCO to drive XCLK before and it worked, if you look at OpenMV’s schematics, XCLK is connected to the MCO1/TIM1-CH1 pin.

The only problem was that HSI is 16MHZ which results in a 64MHz PIXCLK output (or more) from the sensor, which is outside of the STM32F4’s specs (max PIXCLK 54MHz) so right now I’m using TIM1/CH1 instead.

Edit:

See the comments here:
https://github.com/openmv/openmv/blob/master/src/omv/sensor.c#L182

#6

Hi everyone,

Thanks for your replies.

I don’t think there is anything wrong by feeding the output of the MC0 pin as the XCLK to the camera. The problem was that my MC0 clock signal was derived from HSI not HSE. Hence the whole MCU system was synchronised to HSE, but the camera was using HSI. I made sure PCLK was slow (I think through CLKRC register, but don’t remember). I made sure with a scope that PCLK was 7 or 10 or 12 MHz depending on CLKRC settings, but I was still getting the corruption issue. Basically, no matter how slow I make PCLK, the corruption issue was present. Since I switched to using output of TIM1 as XCLK the problem went away. I suspect if I just changed MC0 to use HSE instead of HSI that would have solved the problem as well (but I haven’t tried this yet).

In summary, I believe the HSI was the problem, either because it is not derived and hence not synhcronised with the rest of the system which runs off of HSE, or because HSI is generally crap being an RC oscillator inside of the MCU.

Regards,
-Igor