DCMI interface doubles the image

[dgiovanelli]

Hello,

I'm working on a DCMI to USB video class converter which runs on a STM32L496. The image sensor is a custom grayscale level sensor developed by my institution. It is 640x480, 8 bit per pixel, however to simplify the things I configured the DCMI interface to select only 1 line out of two and same for the pixel (I use DCMI_LSM_ALTERNATE_2 and DCMI_BSM_ALTERNATE_2 during DCMI initialization).

The problem is that when I monitor the image using VLC the image is weird (see below) and I can't find the source of the problem.

What I see are two problems (that might be only one having two consequences):

• one pixel out of two is black
• the image looks folded on itself

In fact you can see the tip of my fingers on the right of the image while the 'body' of the finger is in on the left, and when I move the hand I see these things overlapping.

Another weird fact that might help finding issues is that if I configure the DCMI interface to sample one frame out of four (DCMI_CR_ALTERNATE_4_FRAME), it generates the HAL_DCMI_LineEventCallback even for lines belonging to the skipped frames. In other words for each call to HAL_DCMI_FrameEventCallback, I get 1920 calls to HAL_DCMI_LineEventCallback (and not 480 as I expected).

Do anybody have ever seen similar effects?

Is it normal that HAL_DCMI_LineEventCallback do not skip events of discarded frames?

Any other idea?

Thank you,

Davide.

[Tesla DeLorean]

X-Ray?

Definitely looks to be some weird interpolation horizontally and vertically, like a diffraction grating. You might want to do a raw capture of the data on the DCMI vs what you're able to capture as a byte stream on the STM32 memory side. Work with the people who built/designed the sensor to validate the data, or provide test/simulated imagery/signalling.

The line length (display) does not like it is long enough. Like the data is 8-bit, stored in 16-bit, or you have a group of data pixels, and a group of black pixels, the groups are the same size, but >1 pixel. You could likely process that out of the data, in doing so you might better understand what's happening, and either associate that with settings on the capture side, or with the design/configuration of the sensor.

Anyway goes back to my first point, understand the data stream, and how that represents in memory, and whose side of the fence the issue is on.

[dgiovanelli]

Maybe they didn't tell me it is an Xray sensor, and that's the reason why I see through my hand! No I'm kidding, it is an ultra low power graylevel image sensor. The sensor designers gave me the spec of the hardware interface and it is DCMI compatible. However I'll connect a logic analyzer to verify it.

It could be also a problem with the DMA (such as a wrong increment in on the memory side), but for the best of my knowledge it is correct (there is an application note describing a similar application and I followed it).

[Tesla DeLorean]

It could be a bit/byte/word packing or ordering issue. Not sure it explains the empty lines.

[dgiovanelli]

Might a byte order inside the 32bit words create the folding/shadow effect? I'm not sure I checked the byte order in the DR register of the DCMI vs the expected byte order of the USB Video Class Device.

However, if the byte ordering was wrong I expected something like:

LINE1: Pixel4;Pixel3;Pixel2;Pixel1 ; Pixel8;Pixel7;Pixel6;Pixel5 ....

....

Therefore the image would be distorted, but in a different way.

And of course black lines are not explained by this.

[dgiovanelli]

So it is definitely a problem with the sensor. It is supposed to have 640x480 resolution however for each line there are 1280 pixel clock cycles.