Corrupt images from the OV5640-STM32F4 interface

[ADani]

I am receiving corrupt images from OV5640-STM32F4. This isn't regular, I get proper images of resolution 320x240 to 5MP, but occasionally I keep receiving corrupt images. The corrupt images are found in all resolution. By corrupt image I mean, sometimes the image color is wrong, sometimes the pixels are shifted, sometimes half the image is missing. I pick the image from SDRAM and transfer it over UART. I suspected it was because the DCMI is overflowing or some error.

I set the FRAME COMPLETE, OVERRUN and ERROR interrupt of DCMI along with frame capture interrupt. When I debug even though I receive corrupt images, I don't get any error callbacks, I only get a FRAME capture call back.

Does that mean DCMI is not the one causing the corrupt images?

What might be the reason for obtaining random corrupt images?

[Tesla DeLorean]

Perhaps you can expand with some detail?

Show more information on how you're doing things now, the configuration and code, and what the resultant image looks like currently. ​

[ADani]

I am using a 16MHz external crystal for clocking the OV5640. The APB2 is 90MHz. The MCU is operating at 180MHz.

I write the values obtained from app note of OV5640, modified the OV5640 clock register to output 24MHz, 42MHz etc.,. for the PCLK. I also changed the quantization register from 0xC to 0x1 to obtain JPG image of high quality. (I reverted back to 0xC and tested. The occasional corrupt image problem persists. It also persists for all PCLK values)

The SDRAM is 8MB which comes along with the discovery board.

I enabled all FRAME COMPLETE, OVERRUN and ERROR interrupt. Start the capture in SNAPSHOT mode.

If I get a frame complete callback, I read the jpg image header from SDRAM and transfer it to PC over UART.

At the end of UART transfer I start the next capture in SNAPSHOT mode.

I only get a transfer complete callback. Not getting an error callback even when the image is corrupted.

[ADani]

I found a lead.

After receiving a corrupt image, instead of taking a new image I read the same address again to see what happens.

To my surprise I get a proper image this time.

I'm not sure why when I read it the first time it was corrupted.

[Amel NASRI]

Hi @ADani​ ,

I'm not a DCMI expert, so I'll not be able to answer deeply your questions. However I suggest you to have a look to AN5020 (Digital camera interface (DCMI) for STM32 MCUs).

This document explains DCMI features and provides recommendations regarding its configuration.

-Amel

[ADani]

Hello @Amel NASRI​ 

I was testing the device and came up with some findings. I will post it here. If you know the reason for this it would be great.

I narrowed down the issue to SDRAM read. The SDRAM was interfaced over FMC.

I found the errata sheet of STM32F42xx where I found the FMC where there were numerous cases which suggested that FMC doesn't go along with interrupts. Placing the link for the errata sheet here.

https://www.st.com/resource/en/errata_sheet/dm00068628-stm32f427437-and-stm32f429439-line-limitations-stmicroelectronics.pdf

I had the SDRAM read inside the frame complete callback. I moved it to the main loop and since then I haven't got any corrupt data. Under section 2.3.4 it is mentioned that if an interrupt occurs during FMC read operation there can be corrupt data. Can the corrupt data happen even if I read the FMC inside an interrupt callback? Seems so, but I would like to know the actual reason behind it.

[M.Hajji]

Hello @ADani​,

Very good to have the issue narrowed to SDRAM Read, for the errata I suggest to see if you have the specific conditions for entry 2.3.5 and 2.3.15 for example the RBURST bit, doing Burst instruction to the FMC (LDM = Load Multiple instruction) and if the issue happen with a end of Row...

Executing SDRAM read (read loop maybe) inside interrupt handler isn't the best of practices as in handlers should avoid loops and heavy work.

Maybe try to disable_IRQ before SDRAM read and enable after and see if solve the issue.

This is just hypothesis but maybe executing SDRAM read in handler mode (following an interruption) vs thread mode (main program, no exception) modified how the access is done and so corrupted some data, maybe what actually solved your issue is changing the execution mode from handler to thread.

Regards,

Mahmoud.

[ADani]

corrupt data are being received even when I read them from the main loop. The frequency of occurrence is low.

[ADani · Accepted solution]

I tried sending the same image thrice over UART, one image is broken and the other two were not. That's when I understood the issue is because of UART transmission. After including a checksum verification to the data transfer the issue is solved. Posting this in case someone comes up with similar issues.

Thank you all for taking the time in helping me. �?��?