2025-11-24 2:07 AM - edited 2025-11-25 3:23 AM
Hello,
We have developed an image capturing application successfully based on STM32H7xxxx and OV7725 camera. We are now targeting to port the application to target STM32U5xxxx with the same camera. But it looks the DMA doesn't works as expected. The DCMI DMA complete callback is firing with no image data in the target buffer.
Please guide us how to port the application from H7 to U5.
Best regards-
Shubhendu Bikash Banerjee
Attaching here snaps of the configurations we made so far.
DCMI GPIO
DCMI NVIC
DCMI parameters
GPDMA1 channels
GPDMA1 CH0
GPDMA1 security
Code snippet:
#define IMAGE_FRAME_WIDTH 320
#define IMAGE_FRAME_HEIGHT 240
#define IMAGE_BYTES_PER_PIXEL 2
#define IMAGE_BYTES_COUNT (IMAGE_FRAME_HEIGHT * IMAGE_FRAME_WIDTH * IMAGE_BYTES_PER_PIXEL)
static uint32_t gDCMIBuff[IMAGE_BYTES_COUNT / sizeof(uint32_t)] = { 0 };
static volatile bool gWaitForFrame = false;
CaptureFrame{
gWaitForFrame = true;
halReturn = HAL_DCMI_Start_DMA(&hdcmi, (uint32_t) DCMI_MODE_SNAPSHOT,
(uint32_t) gDCMIBuff, (uint32_t) imageSize);
if (HAL_OK != halReturn) {
SERVICE_LOGE(TAG, "DCMI start error: 0x%.8X", HAL_DCMI_GetError(&hdcmi));
exeStatus = ERROR_GEN_FAILURE;
goto label_exitPoint;
}
#if LOG_LEVEL >=LOG_LEVEL_DEBUG
SERVICE_LOGD(TAG, "Frame capture started.");
#endif
while (gWaitForFrame) {
__asm__("nop");
}
HAL_DCMI_Stop(&hdcmi);
SetCameraToSleep(pvCameraSensor);
}
void HAL_DCMI_FrameEventCallback(DCMI_HandleTypeDef *hdcmi) {
HAL_DCMI_Stop(hdcmi);
gWaitForFrame = false;
}
This is for reference:
2025-11-26 9:08 AM
This sounds very similar to my observation wrt the STM32U5 GPDMA for SPI, specifically what I saw using DMA for SPI3 RX and TX: both the TX and RX GPDMA 'TC' IRQ's fired (in that order TX then RX) and I saw the SPI3 SCLK clocking, but no data on the SPI3 MOSI (and thus no data in buffer pointed to by DMA for SPI MISO, since I jumper-wire loopback the MOSI data).
https://community.st.com/t5/stm32-mcus-products/stm32u5-spi-gpdma-cannot-get-simple-loop-back-data-working/td-p/858555
I will bookmark your post to see if you find a solution first.
2025-11-28 3:54 AM
Update:
I can now capture frames. But there is a problem, the frame get's splitted in the buffer. The scenario looks like a horizontal part from lower part of the frame is placed at upper position.
Sample
2025-12-11 6:07 AM
Hello @shubhenduatadben ,
What is the DCMI_PIXCLK frequency? Could you please try reducing the clock frequency.
I recommend you to look at DCMI_ContinousCap_EmbeddedSynchMode example and precisely the DCMI_ContinousCap_EmbeddedSynchMode.ioc file and get inspired to check the DCMI and GPDMA configuration.
Thank you.
Kaouthar
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2025-12-12 4:26 AM
Hi @KDJEM.1
Thank you for your suggestions. I can't reduce the DCMI_PIXCLK, which is running at 12MHz right now. As I can remember, current DCMI_PIXCLK is well under DCMI spec.
I've found that the DCMI is filling the buffer assuming the frame as square,i.e. the current WIDTH x HEIGHT = 320 x 240 but the DCMI assumes frame of 320 x320.
If I provide a 320 x 320 compatible buffer, the DCMI is collecting the frame but the top 80 lines are blank(black) and I get the actual image as 320 x 240.
2025-12-12 7:38 AM
Hello @shubhenduatadben ,
Thank you for updating post and for these information.
For this resolution, I recommend you to enable the GPDMA circular mode.
Please let me know if the issue is solved or not?
Thank you.
Kaouthar
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.