Are there in-depth ways to investigate why HAL_DCMI_Start_DMA() is not putting data into the"*pdata" pixel buffer?

[KM.8]

I am getting pixel data to the stm32. I am reaching the "end of frame flag clearing" at:

stm32l4xx_hal_dcmi.c ----> HAL_DCMI_IRQHandler() ----> (line 811)__HAL_DCMI_CLEAR_FLAG(hdcmi, DCMI_FLAG_FRAMERI);

I am simply checking cameraBuffer[] pixel array using SNAPSHOT and CONTINUOUS modes without success.

I am working on a DCMI camera interface between the NUCLEO-L496ZG board and a MT9V024 10-bit monochrome camera sensor used in 8-bit configuration. I have successfully been able to set the MT9V024 sensor to "capture mode" to retrieve a single pulse and give me 8 bits of data (using MT9V024 D2 through D10 and skipping two LSB pins B0 and B1). This will omit the two LSB data, but keep the upper eight bits. The MT9V024 is using 752x480 8-bit parallel frames, which use the HAL_DCMI_ConfigCROP() function in order to reduce the size of the image to 376x240. I set HAL_DCMI_Start_DMA(WIDTH*HEIGHT/4) since there are 32-bit words for DMA and 8-bits per pixel, so 4 pixels per word. I included the schematics and the images of the Digilent logic analyzer for the debugging process. Please let me know if more information is required. I am using the onboard 27MHz clock on the MT9V024 development board. I was not able to get a fully functioning project using an OV7670 RBG565 camera sensor, but I was able to at least get 16-bit pixel data as values in cameraBuffer[] using the same code structure I am using presently. If anyone is able to help, it will be greatly appreciated.

MT9V024 development board (schematic attached with overview with diagrams in next link): 

https://www.onsemi.com/PowerSolutions/evalBoard.do?id=MT9V024IA7XTMD-GEVK

MT9V024 datasheet: 

https://www.onsemi.com/PowerSolutions/product.do?id=MT9V024

stm32CubeMX project generation and code is included as a .zip file.

[KM.8]

STILL UNRESOLVED, but more questions if anyone can help with debugging the DCMI/DMA usage.

I decided to use the binning feature of the MT9V024 camera instead of using the crop feature of the HAL software. The data being written to the stm32 is verified to be 376x240 using the FPGA configuration with register R0x0D register value of 0x0305. This verification is shown in the attached image.

"stm32l4xx_hal_dcmi.c" - Line 1264

DCMI_DMAXferCplt() is being called, but since the image size is 376x240, the DMA is not deeming the transfer as a "large transfer".

line 510 states:

hdcmi->XferCount = 0;

QUESTION 2: (thread question 1 is still to identify why *pdata is empty)

from this, should I assume that DCMI should write to the destination of cameraBuffer[] (*pdata pointer to HAL_DCMI_Start_DMA()?

"stm32l4xx_hal_dcmi.c" - Lines 1322&1325

DCMI_DMAXferCplt() is being called. The logic steps to 1322 during debugging, but the logic does not get to line 1325.

"stm32l4xx_hal_dma.c" - Line 862

HAL_DMA_IRQHandler() calls "hdma->XferCpltCallback(hdma);"

QUESTION 3:

Where does the DMA process go from here?

QUESTION 4:

If the DMA transfer was complete, why isn't there data in the DMA transfer destination (where HAL_DCMI_Start_DMA's *pdata points to)?

[KM.8]

Updated logic analyzer waveform where there are two Hsync pixel frames before the actual image data travels from the camera to the microcontroller.

[KM.8]

Uploaded 376x240 code.

I am still unsure how to debug the DMA not writing to the HAL_DCMI_Start_DMA()'s *pdata parameter.

[waclawek.jan]

Read out the GPIO, DCIM and DMA registers' content and check if they contain what you expect they should.

JW

[KM.8]

Attached are the register outputs.

Error stems from "stm32l4xx_hal_dma.c" HAL_DMA_Abort_IT(), line 625

hdma->ErrorCode = HAL_DMA_ERROR_NO_XFER;

I am at a loss on how the DMA is not working with this camera.

I will continue to check the clock, Hync, Vsync polarity again to make sure the DCMI configuration is correct. I did change the resolution back to the original MT9V024 resolution of 752x480, I then set the stm32CubeMX to "interface captures every other byte from the received data" to make the resolution 376x480. This was unsuccessful.

[KM.8 · Accepted solution]

I finished the interface between the MT9V024 camera sensor and the stm32L496ZG NUCLEO BOARD.

The issues were:

1) Hsync and Vsync were "when data is valid" for MT9V024 output.

I had to make DCMI active low for both Hsync&Vsync since DCMI uses Hsync&Vsync for when the data is not valid from the camera.

2) DMA was overruning the DMA buffer. If you look at the DCMI specification document, the stm32L496 can only operate in "single buffer mode", which means it can only read 262140 bytes per DMA transfer:

https://www.st.com/resource/en/application_note/dm00373474.pdf

The resolution programmed in this example is 512x480x[1bytePerPixel8bitMonochrome]==245760 bytes. The image resolution is under the max single DMA transfer threshold.

NOTE: DCMI is using MT9V024 D2 through D10 (D0 and D1 are unused since they are the LeastSignificantBits) for each pixel.

Software with stm32CubeMX is attached for use as needed.

Thank you waclawek.jan for your assistance.

I am not sure how to close this thread.

Could someone please close this thread for me if an admin sees this post?

[KM.8]

I am using the following link to verify the images. The BITMAP file writing is still incorrect, but the DCMI/DMA interface is working correctly with the MT9V024 XMCLK Clock of 27MHz.

http://rawpixels.net/