2022-10-13 01:55 AM
Hello,
My architecture is based on STM32H750 with an external memory mapped SDRAM used to store the framebuffer and -willingly- used to store at runtime assest such as texts fonts and images.
I’ve modified my linker file to:
MEMORY
{
FWINFO (rx) : ORIGIN = 0x24000000, LENGTH = 16
FWVER (rx) : ORIGIN = 0x24000100, LENGTH = 256
RAM_EXEC (xrw) : ORIGIN = 0x24000200, LENGTH = 523776
DTCMRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
RAM_D2 (xrw) : ORIGIN = 0x30000000, LENGTH = 288K
RAM_D3 (xrw) : ORIGIN = 0x38000000, LENGTH = 64K
ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K
SDRAM (xrw) : ORIGIN = 0xC0400000, LENGTH = 4096K
SDRAMASSETS(xrw) : ORIGIN = 0xC0000000, LENGTH = 4096K
}
[…]
FontSearchFlashSection :
{
*(FontSearchFlashSection FontSearchFlashSection.*)
. = ALIGN(4);
} >SDRAMASSETS
TextFlashSection :
{
*(TextFlashSection TextFlashSection.*)
. = ALIGN(4);
} >SDRAMASSETS
FontFlashSection :
{
*(FontFlashSection FontFlashSection.*)
. = ALIGN(4);
} >SDRAMASSETS
ExtFlashSection :
{
*(ExtFlashSection ExtFlashSection.*)
. = ALIGN(4);
} >SDRAMASSETS
SDRAM will contain the frambuffer, while SDRAMASSETS will contain the font and images sections.
I wrote an external loader which loads assets in the external SDRAM before firmware execution. I’ve checked that the copied binary is byte-to-byte with the expected binary file. To do this I’ve executed after compile the command:
call arm-none-eabi-objcopy.exe -O binary -v --gap-fill 0xff FW08_Application.elf FW00_Application_SDRAM.bin -j FontFlashSection -j ExtFlashSection -j TextFlashSection -j FontSearchFlashSection
and checked with a tool (winmerge) that is exactly what is written in SDRAM memory.
The application runs (it’s just a test application) but I get even characters garbled: 0 is ok, 1 garbled, 2 ok, 3 garbled.
Running the exact same application but changing
FontFlashSection :
{
*(FontFlashSection FontFlashSection.*)
. = ALIGN(4);
} > RAM_EXEC
Makes it work perfectly: see picture below.
Any hints on how to solve this?
2022-10-13 02:20 AM
Some more notes. I've tried the same application:
provided same result.
Moving FontFlashSection into ITCMRAM works, but my goal is to move into external SDRAM.
2022-10-13 02:33 AM
Another note:
I've placed a breakpoint in the GeneratedFont.cpp function getPixelData:
const uint8_t* GeneratedFont::getPixelData(const GlyphNode* glyph) const
{
const uint8_t* const* table = (const uint8_t* const*)glyphData;
return &(table[glyph->unicode / 2048][glyph->dataOffset]);
}
And with memory browser I've downloaded the data at the returned address.
For glyph 0 I get
for glyph 1 I get:
So glyphs are ok. What's going on with the library?
2022-10-13 08:12 AM
Why you not use memory mapped QSPI flash ?
Seems loading glyphs from same memory as framebuffer, but different page, isnt good idea.
Too check caching setup.
2022-10-13 11:00 PM
QSPI pins are used by LTDC so I discarded this possibility.
It seems related to SDRAM access. Everything works if I get 1 byte at once from SDRAM, but if I'm accessing WORDs... It works with addresses multiple of 4 and returning 0 if accessing (address+2)%4==0
i.e. Accessing 0xC0000000 is ok,
Accessing 0xC0000002 returns 0, but reading one byte after another I read the correct content.
Now I'm back working on the FMC to solve this. I'll update later.
2022-10-14 08:31 AM
Try check Reading 8 bit arrays from external SDRAM in STM32H7 gives corrupt data
too check signals on pins for shorts or disconnects.