STM32U575 DCMI GPDMA Vertical Blanking

[f3l1xa88077]

Hiya.

I’m currently trying to capture an image from the OV7670 camera module over DCMI + GPDMA. I’ve been able to capture images, but I’ve run into an odd issue with vertical blanking. Using the STM32U575RIT3. I have the module configured for RGB565 in QVGA and I can fully confirm that it is outputting what it is meant to, the issue is just with GPDMA and getting it into memory.

In GPDMA=Standard Request, I only get ¾ of the image, with the first ¼ being blanked.

 

Sample image in GPDMA Standard Request

In Linked List mode, I can only seem to get up to ½ of the image. I get ¼ with a single node, ½ with two nodes, but no more when introducing more nodes.

Sample image in GPDMA Linked List Mode

I can confirm that the GPDMA_CxDAR register shows that it has indexed by an entire image and reached the FrameEvent callback in StandardRequest Mode. In LinkedList mode, it seems to just lost the second half of the image as I do not get the callback and the DAR register records an increment of half the image.

Some notes:

• I’ve seen mention about the 64 kB boundary of LinkedList mode, but I’m not sure how to work around this if it really is the underlying issue.
• When I incorrectly configure the camera I receive an entire frame’s worth of information, no vertical blanking (in standard request mode).
• I have tinkered with the camera config to get a full frame in standard request mode, but the output image is stretched (as if it was stretched vertically to cover up the blanking).

Sample photo of stretched image.

• I have aligned the buffer: ALIGN_32BYTES(uint32_t pBuffer[MAX_PICTURE_BUFF]);

• I have configured the GPDMA (and LL) to use words, increment on destination and not source.

• I am using the memory browser to verify that the vertical blanking is a result of 0s and not a post-processing issue.

• The image is QVGA (320x240), which is 76,800 pixels. In RGB565 for this camera, one pixel occupies two bytes, so the total size should be approximately 153.6 kB. It is also less than the max image size in Table 11: https://www.st.com/content/ccc/resource/technical/document/application_note/group0/c0/ef/15/38/d1/d6/49/88/DM00373474/files/DM00373474.pdf/jcr:content/translations/en.DM00373474.pdf

Since I’m getting most of the image, I’m assuming this isn’t a camera issue, rather an issue with configuring the GPDMA. I’m very new to GPDMA though, so the problem could be quite obvious!

Moving forward I’m hoping to understand the underlying issue behind both approaches (standard request and linked list) so I can better understand GPDMA and choose the better approach :).

[KDJEM.1]

Hello ​@f3l1xa88077 ;

 

The linked-list is mandated for circular mode.

I recommend you to look at 17.4.13 GPDMA circular buffering with linked-list programming section in RM0456.

For more information about the GPDMA , I recommend you to look at

• How to use the GPDMA for STM32 MCUs application note.
• How to configure the GPDMA 
• How to configure the linked list mode in STM32CubeMX

Note that, the GPDMA can transfer data blocks in bytes, with a maximum block size of 64 kbytes - 1.

Please look at DCMI_ContinousCap_EmbeddedSynchMode may help you.

 

Thank you.

Kaouthar

[f3l1xa88077]

Thanks for the reply.

Before the post I had already looked at those resources and tried to align my code with the GitHub repo example (your last link). I’ve taken another look and I’m not seeing anything sticking out yet.

I’m working with a 4-node linked list at the moment, but only the first two nodes are carrying data, not the third or fourth. 

[KDJEM.1]

Hello ​@f3l1xa88077 ,

 

Do you get the same issue with horizontal blanking?

 

Thank you.

Kaouthar

[f3l1xa88077]

No, only vertical blanking. This is consistent with the LL nodes being the issue as it cuts off at the end of the second node (each node occupies ¼ of vertical space).

I’m not sure why 1 & 2 node configurations work but 2+ does not.

[f3l1xa88077]

Instead of doing config through CubeMX, I did it manually by code and got the implementation to work. I was having issues linking any node that came after the first two (as I’m assuming the compiler ignores all other nodes when running in double-buffer). By manually setting the linkregisters, I was able to get all-four nodes working and got a full image.

Although it was solved, it would be very nice to be able to do this through CubeMX.

All I needed to do was set the global node size:

pNodeConfig.DataSize = IMG_SIZE / NUM_NODES; // Ensure below 38400

and for each node, manually set the destination address before creating each node:

pNodeConfig.DstAddress = (uint32_t)&pBuffer[0];

ret |= HAL_DMAEx_List_BuildNode(&pNodeConfig, &DCMI_Node1);

ret |= HAL_DMAEx_List_InsertNode_Tail(&DCMIQueue, &DCMI_Node1);

This should be done in either the linked_list.c file in core/src, or in a different one (that doesn’t get overwritten by cubemx).