DCMI DMA interrupt on STM32F746 disco board

[mecurioustolearn]

I'm currently working with the STM32F736 Discovery board and an OV5640 sensor. I've successfully configured the DCMI for snapshot mode and enabled DCMI DMA interrupts. However, I've encountered an unusual issue. While I observe that the capture bit clears after frame completion, I'm not receiving a DMA interrupt as expected.

In my current setup, I've been relying on the DMA interrupt to signify the completion of a frame. Unfortunately, this approach doesn't seem to be functioning as expected, as the 'hcamera_dcmi.State' isn't transitioning to 'HAL_DCMI_STATE_READY.'

As an alternative, I've been depending on the 'CR.Capture' bit to signal frame completion. However, it appears that the frame time is longer than anticipated. I'd greatly appreciate any insights or guidance on addressing this issue.

Thank you.

[FBL · Accepted solution]

Hello @mecurioustolearn 

Can you check OVR_IE bit field in DCMI_IER to check whether it is related to an overrun? If so, try to increase the DMA buffer size. Also, you can try to increase the memory bandwidth using faster clock for example.

[mecurioustolearn]

Thank you for your response. I've observed a few unusual occurrences:

1 In the HAL_DCMI_Start_DMA function, the HAL_DMA_Start_IT function consistently returns a failure, preventing the DMA from starting. However, upon debugging, I've discovered that HAL_DMA_Start_IT actually returns "HAL_OK." For some reason, the conditional statement in HAL_DCMI_Start_DMA incorrectly evaluates as true, causing it to return "HAL_ERROR." To aid in debugging, I've chosen not to rely on the return value of the HAL_DMA_Start_IT function and have continued with the HAL_DCMI_Start_DMA function. Consequently, I've noticed that the DMA completion callback function gets invoked, subsequently triggering the frame completion interrupt. The frame completion ISR is also activated. I lack an explanation as to why the "if" condition for HAL_DMA_Start_IT is evaluated as true in HAL_DCMI_Start_DMA.

2 Each frame appears to take approximately 230 milliseconds. However, disabling Dcache and Icache has resulted in some improvement in frame timing, reducing it to around 180 milliseconds. Unfortunately, the post-processing is adversely affected due to cache deactivation, resulting in poor timings.

3 To mitigate the caching issue, I attempted to place the captured frame in DTCM memory where caching wouldn't occur. Strangely, after doing so, the timings worsened.

4 I'm currently attempting to capture data in RGB565 format with a resolution of 96x96 pixels. I've allocated a buffer in the DTCM RAM area with a size of 96x96x2. However, with this allocation, the received frame appears to be corrupted. When I allocate a size of 96x96x3, the received frame appears to be correct.

I would greatly appreciate any assistance or insights you can provide regarding these issues.

[FBL]

Hello again @mecurioustolearn 

1. Could you provide more details about the context (Hardware and Software setup, DMA Configuration, memory used ...) to reproduce the behavior on myside to confirm the bug? As far as I understand, only one possible explanation for this behavior is that is HAL_DCMI_Start_DMA function is not properly handled.
2. The DMA must ensure the transfer of one single frame from the DCMI to the desired memory in normal mode. Does the DMA instance serve other streams in parallel with the DCMI?
3. 4. To reach the best performance, follow the recommendations listed in the AN5020.section 7.2 
   Also, check DCMI interconnection and data path between DMA and DTCM RAM.