Add support for B-CAMS-OMV shield on STM32H747 disco

[dkouba-atym]

This PR is a WIP to add support for the ST B-CAMS-OMV shield to the STM32H747I Discovery board.

In the process I have ported the changes from #91506 to the H747 board to support the onboard SDRAM.

I am currently having trouble with two things:

1. When I disable SMH and only use internal memory, the capture starts but I never see the message for completed frames
2. When I use SMH, the above happens, and after a variable number of DCMI frame callbacks the DMA overflows and we get error 0x41 from the DCMI.

Example of what happens with SMH enabled:

*** Booting Zephyr OS build v4.2.0-rc1-32-g482b02304b3d ***
[00:00:00.172,000] <inf> main: Video device: dcmi@48020000
--- 4 messages dropped ---
[00:00:00.172,000] <inf> main: - Capabilities:
[00:00:00.172,000] <inf> main:   RGBP width [160; 160; 0] height [120; 120; 0]
[00:00:00.172,000] <inf> main:   RGBP width [320; 320; 0] height [240; 240; 0]
[00:00:00.172,000] <inf> main:   RGBP width [480; 480; 0] height [272; 272; 0]
[00:00:00.172,000] <inf> main: - Video format: RGBP 160x120
[00:00:00.177,000] <inf> main: - Supported frame intervals for the default format:
[00:00:00.177,000] <inf> main: - Supported controls:
[00:00:00.177,000] <inf> main:          device: ov5640@3c
[00:00:00.177,000] <inf> video_ctrls:                       Brightness 0x00980900 (int)    (flags=0x00) : min=-15 max=15 step=1 d
[00:00:00.177,000] <inf> video_ctrls:                         Contrast 0x00980901 (int)    (flags=0x00) : min=0 max=255 step=1 de
[00:00:00.177,000] <inf> video_ctrls:                    Vertical Flip 0x00980915 (bool)   (flags=0x00) : min=0 max=1 step=1 defa
[00:00:00.177,000] <inf> video_ctrls:             Power Line Frequency 0x00980918 (menu)   (flags=0x00) : min=0 max=3 step=1 defa
[00:00:00.177,000] <inf> video_ctrls:                                  0: Disabled
[00:00:00.177,000] <inf> video_ctrls:                                  1: 50 Hz
[00:00:00.177,000] <inf> video_ctrls:                                  2: 60 Hz
[00:00:00.177,000] <inf> video_ctrls:                                  3: Auto
[00:00:00.177,000] <inf> video_ctrls:                    Analogue Gain 0x009e0903 (int)    (flags=0x0c) : min=0 max=1023 step=1 d
[00:00:00.177,000] <inf> video_ctrls:                       Pixel Rate 0x009f0902 (int64)  (flags=0x01) : min=24000000 max=960000
[00:00:00.177,000] <inf> video_ctrls:                     Test Pattern 0x009f0903 (menu)   (flags=0x00) : min=0 max=4 step=1 defa
[00:00:00.177,000] <inf> video_ctrls:                                  0: Disabled
[00:00:00.177,000] <inf> video_ctrls:                                  1: Color bars
[00:00:00.177,000] <inf> video_ctrls:                                  2: Color bars with rolling bar
[00:00:00.177,000] <inf> video_ctrls:                                  3: Color squares
[00:00:00.177,000] <inf> video_ctrls:                                  4: Color squares with rolling bar
[00:00:00.177,000] <inf> main: Alloc buffer[0]: 38400 bytes
[00:00:00.177,000] <inf> main: Alloc buffer[1]: 38400 bytes
[00:00:00.178,000] <inf> main: Alloc buffer[2]: 38400 bytes
[00:00:00.178,000] <inf> main: Capture started
[00:00:00.231,000] <inf> video_stm32_dcmi: HAL_DCMI_FrameEventCallback OK
[00:00:00.269,000] <inf> video_stm32_dcmi: HAL_DCMI_FrameEventCallback OK
[00:00:00.308,000] <inf> video_stm32_dcmi: HAL_DCMI_FrameEventCallback OK
[00:00:00.347,000] <inf> video_stm32_dcmi: HAL_DCMI_FrameEventCallback OK
[00:00:00.386,000] <inf> video_stm32_dcmi: HAL_DCMI_FrameEventCallback OK
[00:00:00.424,000] <inf> video_stm32_dcmi: HAL_DCMI_FrameEventCallback OK
[00:00:00.463,000] <inf> video_stm32_dcmi: HAL_DCMI_FrameEventCallback OK
[00:00:00.521,000] <inf> video_stm32_dcmi: HAL_DCMI_FrameEventCallback OK
[00:00:00.560,000] <inf> video_stm32_dcmi: HAL_DCMI_FrameEventCallback OK
[00:00:00.599,000] <inf> video_stm32_dcmi: HAL_DCMI_FrameEventCallback OK
[00:00:00.638,000] <inf> video_stm32_dcmi: HAL_DCMI_FrameEventCallback OK
[00:00:00.677,000] <inf> video_stm32_dcmi: HAL_DCMI_FrameEventCallback OK
[00:00:00.715,000] <inf> video_stm32_dcmi: HAL_DCMI_FrameEventCallback OK
[00:00:00.754,000] <inf> video_stm32_dcmi: HAL_DCMI_FrameEventCallback OK
[00:00:00.793,000] <inf> video_stm32_dcmi: HAL_DCMI_FrameEventCallback OK
[00:00:00.851,000] <inf> video_stm32_dcmi: HAL_DCMI_FrameEventCallback OK
[00:00:00.857,000] <inf> video_stm32_dcmi: HAL_DCMI_FrameEventCallback OK
[00:00:00.858,000] <wrn> video_stm32_dcmi: DCMI Error: 0x41

Without SMH enabled, HAL_DCMI_FrameEventCallback continues to return forever, but we never see a completed frame.

I don't know enough about the internals to debug this as quickly as you all might and I would appreciate any pointers.

[github-actions]

Hello @dkouba-atym, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[josuah]

Hello @dkouba-atym and thank you for extending the adapters to one more camera!

DCMI is involved with the parallel port protocol, and offloads all the memory filling to DMA.
HAL_DCMI_FrameEventCallback is mostly a DMA event AFAIU...

It does not look like the frame size require this much RAM, the 1 MByte of on-chip ram should have been able to store the full frame. The STM32H747 was tested 4 days ago via Arduino Nicla Vision (after the merge of #91506 2 weeks ago).

The devkit is different though, with large (32-MByte) external SDRAM. Maybe something in memc_stm32_*.c needs some fixing to keep supporting internal RAM while SMH is enabled. Did you try with CONFIG_SHARED_MULTI_HEAP=n when CONFIG_VIDEO_BUFFER_USE_SHARED_MULTI_HEAP=n.

Possibly related as it is DCMI on the same chip:

• drivers: video: video_stm32_dcmi: Detect and recover from: HAL_DCMI_ErrorCallback #92354

Thanks again for pushing support for it this far!

[dkouba-atym]

Hey @josuah, yes I did try in that configuration — see my note below the log output in my original post.

Without SMH: I never see the "captured frame" log message, despite the DMA continuing to work in the background (continuous HAL_DCMI_FrameEventCallback events). I think something is broken there.

With SMH: I'm hoping to extend support for SMH mostly because we can, but also because there are other cameras that have higher resolutions that we may want support for in the future, for which the internal RAM is insufficient.

Good call on #92354. After a little digging, that is exactly what I have seen when using the SDRAM. Good that I am able to replicate using pure Zephyr...hopefully that helps isolate things.

[josuah]

Bouncing from #92354 (comment)
@KurtE observed that streaming to external SDRAM could be an issue. Maybe the SDRAM is too slow for the speed of the pixel clock, in which case, reducing the pixel rate of the sensor can help.

It seems like the OV5640 driver modifies the pixel clock PLL settings, so that should effectively slow-down the link rather than just insert padding before/after: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/video/ov5640.c#L797-L809

You might be able to just lower the FPS from the application and try again.

[avolmat-st]

FYI:

#92354 (comment)

[avolmat-st]

Bouncing from #92354 (comment) @KurtE observed that streaming to external SDRAM could be an issue. Maybe the SDRAM is too slow for the speed of the pixel clock, in which case, reducing the pixel rate of the sensor can help.

It seems like the OV5640 driver modifies the pixel clock PLL settings, so that should effectively slow-down the link rather than just insert padding before/after: https://github.com/zephyrproject-rtos/zephyr/blob/main/drivers/video/ov5640.c#L797-L809

You might be able to just lower the FPS from the application and try again.

I think the OV5640 runtime clock tree update is only happening in case of CSI2 based sensor. For a DVP sensor this seems to be rather fixed, hence my quick & dirty patch for trial to directly change the register manually.