DCMI bitdepth of STM32H7 for Raw Bayer data

[M. Jeong]

Posted on March 31, 2018 at 18:03

Can a STM32H7 capture 12-bits raw bayer progressive video data? For instance, from an OV5642 image sensor?

I'm looking at the reference manual of the MCU. It can be found from the following link.

http://www.st.com/content/ccc/resource/technical/document/reference_manual/group0/c9/a3/76/fa/55/46/45/fa/DM00314099/files/DM00314099.pdf/jcr:content/translations/en.DM00314099.pdf

 

In section 31.2 it's written that 14-bit progressive raw bayer data is supported.

31.2 DCMI main features

•8-, 10-, 12- or 14-bit parallel interface

•Embedded/external line and frame synchronization

•Continuous or snapshot mode

•Crop feature

•Supports the following data formats:

–8/10/12/14- bit progressive video: either monochrome or raw bayer

–YCbCr 4:2:2 progressive video

–RGB 565 progressive video

–Compressed data: JPEG

However, in the section '31.5.1. Data format' only 8-bits is mentioned.

31.5.1 Data formats

Three types of data are supported:

•8-bit progressive video: either monochrome or raw Bayer format

•YCbCr 4:2:2 progressive video

•RGB565 progressive video. A pixel coded in 16 bi

ts (5 bits for blue, 5 bits for red, 6 bits

for green) takes two clock cycles to be transferred.

31.5.2 Monochrome format

Characteristics:

•Raster format

•8 bits per pixel

Should one assume that it's just a mistake by ST to omit 10/12/14-bits progressive data format? I asked a similar question last year for F7.  At that time people assumed it's a mistake. But it's confusing that ST makes these statements again. What is correct? Is '12-bit per pixel raw bayer video format' supported?

[Tesla DeLorean]

Posted on March 31, 2018 at 19:18

You should discuss with the ST engineers supporting your account.

Pretty sure the interface/DMA is entirely agnostic to the form of the data, at that level it is a parallel word stream of defined width. The ability to process/transcode it on the fly would be dependent on other hardware functionality.

Do you lack the ability to experiment and test the capabilities of the interface?

[T J]

Posted on March 31, 2018 at 23:03

The chip is very new,

there may be an issue at the higher levels which are likely to be fixed in the next/next silicon.

If you could test it and lets us know the result.

the reference manual is what they are aiming to provide.

you could check the errata for the known issues.

If you could work with an FAE, then update the errata if you find an issue.

[M. Jeong]

Posted on April 03, 2018 at 12:55

thank you for the answer. yes, I contacted ST support team and am waiting for their response.

I do not want to spend ~$500 to buy the evaluation board with a SDRAM and take a lot of time to check if it's supported or not. The problem is the logical contradiction in the documents. if the MCU doesn't support that, then ST should just remove 10/12/14-bit from the specifications.

[M. Jeong]

Posted on April 03, 2018 at 12:57

The same contradictions are found from the reference manuals for F4, F7 series. So I don't think this has something to do with temporary issues in the errata. Those descriptions would imply fundamental issues in the product, or would be just mistakes in writing the documents.

[Nesrine M_O]

Posted on April 03, 2018 at 15:15

Hi

Jeong.Minjin

,

This is reported internally for check, I will come back to you ASAP.

Sorry for the inconvenience it may bring.

-Nesrine-

[Nesrine M_O]

Posted on May 09, 2018 at 10:27

Hi

Jeong.Minjin

,

Sorry for the delay to come back to you!

In fact ,

10-12-14-bit progressive video data is supportedin STM32H7 DCMI.

As you already said this is

just a mistake in our

reference manual and will be fixed in coming release of the document.

Thank you very much foryour contribution tothe enhancement of our STM32 documentation

-Nesrine-

[Amel NASRI]

Hello,

This error was fixed in the rev5 of RM0433.

-Amel