H/W JPEG Must use DTCM SRAM (not documented anywhere)

[frackers]

7 months I've been on this trail and now by a process of elimination I discover that the input/output buffers used by the JPEG hardware decode MUST be allocated in the DTCM region. Note that the linker file for the stm32f769 Discovery Demo is broken in this respect as it is missing a definition for ".MCU_Data_section".

Having found this, I can still only decode a single image - subsequent images hang up with constant JPEG DMA interrupts. The QMEM0..2 regions of the JPEG hardware seem to have strange values after the first decode. Do I have to re-init them somehow?

Anyone any clues to what this issue is?

[Tesla DeLorean]

Are you sure it is not just a cache/buffer coherency issue? DMA for SDIO/SDMMC into DTCMRAM avoids a lot of those same issues, as it doesn't use the cache.

[frackers]

If that is the case then how do I fix it other than re-arranging the whole linker map. I'm following the examples in the HAL and they all push the buffers into a named section in DTCM rather than play with the cache settings

[frackers]

It also doesn't answer the question of it working once but never again (despite de-init & re-init)

[Tesla DeLorean]

Well you're going to have to get a handle on the caching and MPU settings if you plan to use other memories, the hardware/dma peripherals are dependent on what actually gets into memory (ie source data and descriptors), and the processor may or may not flush content to that memory, nor be aware the cached content is stale.

MPU settings for Write-Through vs Write-Back

HAL_MPU_ConfigRegion()

SCB_CleanDCache_by_Addr()

SCB_InvalidateDCache_by_Addr()

[Tesla DeLorean]

The JPEG unit is not something I've buried any resources into. It's recurrent use in MJPEG applications would tend to suggest they've verified the implementation in a cyclic fashion. Prod your FAE for better worked examples/demos

[frackers]

"There are none so blind as those who will not see"

I started from one of the Discovery board examples which only decodes a single image - so it never initialises the decoder variables in a programmatic way - it only uses static initialisation!!

Having cleared all the pointers and counter on entry into the decode function all is lightness and I can now decode multiple images, even to getting a few frames per second from an mjpeg AVI file ;)

Many thanks to all who have helped in my journey, such a relief to not have to report ongoing work on hardware jpeg decode at yet another stand-up!