cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H743 memory bandwidth issues with DCMI, FMC, ADC, parallel bus, DMA1, DMA2 / DCACHE issue

rob-bits
Associate II

I am developing a product which has an STM32H743 device. I am designing the firmware for the first PCBA prototype. The product receives 30fps video signal from an 720i analog video decoder through DCMI (every second bytes are stored, all lines, so 360x240 resolution frames are captured) to external SDRAM. The stm32 does an image conversion and sending the converted data from internal RAM to a second processing unit through parallel bus. The second processing unit displays the data. The parallel bus is a 16bit interface, with 10MHz clock (20Mbyte data rate with ~44% duty cycle – 44% reading, 56% idle). And in the during operation, the device captures two channel audio signals as well.

The ideal operation flow is the following:

  • DCMI interface uses DMA1 Stream0 (very high priority, fifo), dma in double buffer mode. DMA moves data from DCMI to FMC external SDRAM. It generates two interrupt signal, half transfer complete and full transfer complete. When full transfer completed the transfer is restarted. With 30FPS I am getting half transfer and full transfer signals, so this seems like working properly.
  • When half transfer completed flag is set, the CPU runs a conversion function lets call ycrycbToRGB16() which converts the ycrycb video format to rgb 16bit format. This function finishes before the full transfer signal are set (<15ms execution time)
  • When full transfer completed, and ycrycbToRGB16() executed which is true, then we give a signal to external processor. It can start reading out the converted data, through the parallel interface (bus enable high). The parallel interface is implemented, at the STM32 side, with a timer capture input and full utilization of GPIO port B. The TIM5 input capture, captures the parallel bus clock signal and triggers a dma transfer (DMA2 Stream0, TIM5_CH1, fifo) to copy data from internal SDRAM to GPIOB port. When all data is read, the external processor signalize this on a GPIO input and goes to idle.
  • ADC capture is running in the background on two channels. Slow channels are used, clock operates on 10MHz maximum, 48ksps,scan conversion mode, DMA circular mode (DMA2 Stream1, the DMA transfer cycle is ~15kHz), this data is also send concatenated with the video capture data.

The whole process must be in synchronization, if there is a pending something or too much calculation time, frames will be skipped and the ideal operation will be not kept.

And the issues that I observing:

  1. The ideal timing requirements are met only if D-CACHE is enabled. In this case everything executed properly the data acquisition runs smoothly without issue. However, the image data contains artifacts. And it is because the DMA2 copies the internal SDRAM content to GPIOB while the CPU still has data in D-CACHE and it did not store the data to internal SRAM, in fact it took approx.  60ms to update all the frame in sram. Here is an example image, with a dummy signal where the color bars changing colors at each vsync event. E.g. the red bar becomes pink and pink bar becomes red. It can be seen some pixel data remains at previous color but most of them are updated and was read out successfully with the parallel bus.
    robbits_0-1725041231489.png

     

  2. If I disable the D-CACHE, the performance drops too much, and the timing requirements of the ideal operation is not met. E.g. the calculation time of the ycrycbToRGB16() function increases from ~7ms to 20ms which is not acceptable. With D-Cache the algo finished sooner, but the data was not there in the internal sram. So either solution is not ok.
    Here is another test frame:
    robbits_1-1725041231491.png

     


    The image does not contain any artifact, but the capture rate dropped to 15FPS instead of 30FPS because of the slowing down to access to SDRAM.
  3. If I increase the clock rate of the parallel bus, from 10MHz to 20MHz the timings are “crashed”. It seems stm32 is missing clocks from the external controller and therefore the data transmission breaks. The clock signal looks like this on the proto (with 20MHz clock):
    robbits_2-1725041231496.png

     

All the parallel bus lines has a 120ohm series resistor now.

Some additional info:

  • The STM32 configured to 480MHz SYSCLK from a 16MHz HSE crystal
  • The FMC is configured to 240MHz FMC clock (SDRAM common clock 2HCLK – 120MHz, CAS latency 3 clock – 80MHz)
  • The TIM5 configured with no preclear and autoload of 2
  • each frame consists of ~320kB data, in double buffer mode it is 640kB data

I think I have some memory bandwidth issues. There must be some wait cycles when the CPU tries to write to internal SDRAM. Or when DCMI/DMA1 writes to external SDRAM and the TIM5 triggers data transfer with DMA2 to GPIO port happens in the same time causes latency.

I am thinking about the following options:

  1. Write code for MDMA or BDMA or DMAMUX or DMA2D controller for more advanced memory action. Especially considering a different domain rams+dma (D1, D2, D3)
  2. using mixed memory usage of D-CACHE + non cached sram. E.g. non cache for parallel bus data
  3. using d-cache but handling cases for sdram preparation before dma transfer e.g. clear/invalidate d-cache
  4. maximize the external SDRAM clock to 200MHz (as the SRAM maximum) and lower the SYSCLK
  5. using different memory layout e.g. smaller internal sram buffers for dcmi and writing data to external sdram with dma when the internal buffer is filled

Is there anything else to improve the acquisition? Do you see any issue with the concept of the ideal operation implementation?

 

11 REPLIES 11
AScha.3
Chief II

Seems to be a problem with the cache management - how you do this ?

(you didnt write about...)

If you feel a post has answered your question, please click "Accept as Solution".

Thanks for the comment. Indeed I do nothing with cache management. Basically in previous projects I used STM32F4xx, L4xx controllers and cache was not a thing there. In STM32CubeIDE I just clicked the "magic" button enable D-CACHE and thats all what I do.

Do you have any great docu about this?

Any advice for best approach for my use case?

What I am unsure, how the data is moving in the internal bus. So when it is writing data to external SDRAM, when it is writing to internal SDRAM and is there any collusion, wait cycles which could be optimized... It would be great to see a measure how this is happening in my use case.

Thanks!

Ok, just think about...the D-cache keeps data from cpu, but if data is changed ( by DMA ) , it still has old data.

You have to "tell" him, to refresh data...

So make a picture/diagram, what data is changed by dma or else, than cpu - and when its used and has to be real/new data, because dma is sending it to ...somewhere.

For cache management you have :

-  SCB_InvalidateDCache_by_Addr(..)  -> delete cache , because now old data

-  SCB_CleanDCache_by_Addr(...)  -> write cache to mem, because cache/cpu has new data and needs write out to update memory

+

all addresses you use for cache management have to be aligned to match the cache access -> like this :

uint8_t inbuf[4096*8] __attribute__ (aligned (32));

 

If you feel a post has answered your question, please click "Accept as Solution".

Thanks, I will examine this in more detail.

Do you think the question #3 is related? ("f I increase the clock rate of the parallel bus, from 10MHz to 20MHz the timings are “crashed”")

Based on my examination with scope and logic analizer, seems like the STM32 could not keep up the handling of the input clock as trigger. So each clock should update the GPIOB port. At clock rate of 10MHz it is working but with 20MHz it does not. And I think 20MHz clock is not that high speed. Of course, considering the lot of stuff running in the background, the cache issue could be related, but let me know your thoughs.


Do you have any great docu about this?


I invite you to have a look at these application notes:

AN4839 Level 1 cache on STM32F7 Series and STM32H7 Series 

AN4838 Introduction to memory protection unit management on STM32 MCUs

AN4891 STM32H72x, STM32H73x, and single-core STM32H74x/75x system architecture and performance

AN4861 Introduction to LCD-TFT display controller (LTDC) on STM32 MCUs Especially the sections 5.5 Graphic performance optimization and 5.6 Special recommendations for Cortex-M7 (STM32F7/H7)

 

 

 

 

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.
LCE
Principal

Do you use an OS?

Make sure that DMA has enough time for bus access, so let the CPU sleep whenever possible.

Without using an OS, I made the mistake not having a "sleep state" in my main state machine, which made the CPU constantly and always check some peripherals and variables, although it was absolutely not needed.

Hardware / 20 MHz:
- the 120 Ohms seem a little high, maybe the flanks are not steep enough for some IO
- have you set all GPIOs to highest speed possible?

LCE
Principal

... but first start with some cache management!

I have no ideas about that, though...

Thanks the input. Makes lot of sense. Indeed, I am not using OS and I have an always running while loop. I will try to add some sleep, it can fit there.

For series resistor, first I used 27R and I changed to 120R that I read from other forums. Basically from datasheet I saw 5pF input capacitance, so with 120R the cut frequency is pretty high still.

For all GPIOB the output speed is very high as they are configured as digital output. For clock input, I am not sure if I can set high speed for timer input. In GPIO config of cubeide I see this:

robbits_0-1725286100224.png

I do not know if it make sense to change the "Maximum output speed". The signal is input. Will check this.

And I have this timer config:

robbits_1-1725286181301.png

 

 

 

LCE
Principal

The speed register settings only apply to outputs. But mind that the data lines to a memory are usually bi-directional.

 

120R: It's not only about the RC-lowpass corner frequency, this is also about flank steepness.