STM32F7xx JPEG Encoder DMA ST example works only in DTCM Ram

[andywild2]

Hello to all,

We are trying to take over the JPEG_EncodingFromFLASH_DMA example from ST running on the STM32F769I_EVAL board.
The original ST software runs fine on the board.
However all the ram data is linked starting from 0x20000000, which is the tightly coupled DTCM Ram.
As in our project the DTCM Ram will be used for Stack and Heap because of its speed, we recompiled the ST example to link the data into 0x20020000. (This SRAM is accessible via the busmatrix only)
If we do this the pixel data in the jpg image is distorted. It is still possible to recognize the original picture, but with lots of pixel erros in it.

So the question is: Why is it essential to have the Input/Output DMA buffers (for feeding the JPEG encoder with data) located in the fast DTCM Ram? When the JPEG encoder triggers a DMA request how is it synchronized if the DMA cannot become a busmaster in the busmatrix immediately?

As the fault can be provoked easily by just linking the data of the untouched! example software to 0x20020000 instead of 0x20000000, I am hoping to get answers to my questions.

Have a nice day

Andy

[SofLit]

Hello,

Did you enable the D-cache for SRAM1 (0x20020000)?

[andywild2]

Hello SofLit,

sure the cache is enabled!
To say it again: I am not talking about my software, but the ST example for JPEG on GitHub.
Here is the link:
https://github.com/STMicroelectronics/STM32CubeF7/tree/master/Projects/STM32F769I_EVAL/Examples/JPEG/JPEG_EncodingFromFLASH_DMA

In main.c you can see that CPU_CACHE_Enable(); is called.

[andywild2]

In the meantime I found this post:
https://community.st.com/t5/stm32-mcus-touchgfx-and-gui/h-w-jpeg-must-use-dtcm-sram-not-documented-anywhere/td-p/242899

So I will play with the MPU in terms of cache for the SRAM1

[SofLit]

Do you mean that the only thing you did is to modify to the linker file of the ST example, so the RAM start of the data location = 0x20020000?

[andywild2]

Yes thats what I did.

But I think the problem is:
DTCM ram works without cache.
SRAM1 works with cache.
Obviously the DMA runs into cache issues.
I will see what I can do with MPU for SRAM1

[SofLit]

Yes it could be something related to a cache data incoherency issue.

Try to disable the cache of the memory used by the DMA using MPU. Simple test: try first to disable the cache and see what happens.

[andywild2]

Yes when disabling the cache all is working fine.
But I need the cache in SRAM1 for the rest of the application, so I can not turn it off permanently.

So it is true what the guy in this post said:
https://community.st.com/t5/stm32-mcus-touchgfx-and-gui/h-w-jpeg-must-use-dtcm-sram-not-documented-anywhere/td-p/242899

The DMA buffers MUST! be in the DTCM Ram.

Thanks for helping me

Andy

[Ozone]

The DMA buffers MUST! be in the DTCM Ram.

This is not uncommon.
Many other cores/MCUs have RAM areas not accessible via all buses, which includes DMA access.
This is usually clearly outlined in the reference manual.

> We are trying to take over the JPEG_EncodingFromFLASH_DMA example from ST  ...

I think you came another distinct weakness of Cube/HAL code.
There is usually little to no documentation of the not-so-obvious design decisions, including (in this case) what RAM to use for DMA buffers, and why.
A decent read of the reference manuals and datasheets is usually obligatory for more serious applications, even if marketing tries to create a different impression.

[andywild2]

Hello Ozone,
Thank you for your reply, that´s very true.

I found out another issue in the JPEG example, which also cost me on day of debugging, maybe it helps other people
or even the JPEG example could be changed?

In encode_dma.c there are the DMA Buffers defined, like:
uint8_t JPEG_Data_OutBuffer0[CHUNK_SIZE_OUT];

In my case, when copying the software the linker placed it to an unaligned adress, so the DMA could not work with it.
It would be more save to implement the buffers like this:
uint32_t JPEG_Data_OutBuffer0[CHUNK_SIZE_OUT/4];

Thus the linker is forced to place it aligned...

best regards to your team

Andy