Hi ST Community,
I’m working on a JPEG encoding pipeline using the STM32N6570 Discovery Kit, and I’m running into an issue when storing both my input and output buffers in PSRAM.
Setup:
- Both JPEG Encoder input (RGB_ImageAddress) and output (jpgBuffer) buffers are placed in PSRAM.
- I’m using RGB888 input format, the same as in the official JPEG example here: JPEG_EncodingFromOSPI_DMA
Linker script (.ld) snippet:
MEMORY
{
AXISRAM1_S (xrw) : ORIGIN = 0x34000400, LENGTH = 1023K
PSRAM (xrw) : ORIGIN = 0x91000000, LENGTH = 16M
}
.psram_section (NOLOAD):
{
. = ALIGN(32);
*(.psram_bss)
. = ALIGN(32);
} >PSRAM
Buffer declarations:
__attribute__((section(".psram_bss")))
__attribute__((aligned(32)))
uint32_t jpgBuffer[160 * 160];
__attribute__((section(".psram_bss")))
__attribute__((aligned(32)))
uint32_t RGB_ImageAddress = {0}; // RGB888 image
Problem:
After running HAL_JPEG_Encode_DMA(...) and reading from jpgBuffer, I get corrupted or incomplete JPEG data:
- The end marker (0xFFD9) is present.
- But the initial bytes (like the JFIF header) are missing or garbage.
- The total JPEG size detected is inconsistent.
What I’ve tried:
- Encoding works perfectly when buffers are in internal SRAM (AXISRAM1_S).
- PSRAM is memory-mapped and accessible (I verified reads/writes).
- D-Cache is enabled using SCB_EnableDCache() in main.c.
- JPEG output buffer is in PSRAM — this seems to be the breaking point.
Questions:
- Does JPEG DMA support output to PSRAM (0x91000000)?
- Do I need to explicitly clean/invalidate D-Cache or configure MPU for this memory region?
- Should JPEG output always be kept in internal SRAM, even if input is in PSRAM?
Main.c is attached below for reference. Any help or insights would be greatly appreciated!
Thanks
