cancel
Showing results for 
Search instead for 
Did you mean: 

FontFlashSection in memory mapped SDRAM

MArri.1
Associate II

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.

0693W00000Unz4CQAR.jpgRunning the exact same application but changing 

FontFlashSection :
	{
		*(FontFlashSection FontFlashSection.*)
		. = ALIGN(4);
	} > RAM_EXEC

Makes it work perfectly: see picture below.

0693W00000Unz4RQAR.jpgAny hints on how to solve this?

5 REPLIES 5
MArri.1
Associate II

Some more notes. I've tried the same application:

  • with both touchgfx 4.15 and 4.20,
  • changing alignment to 4, 8, and other values
  • bit per pixel 4 or 8

provided same result.

Moving FontFlashSection into ITCMRAM works, but my goal is to move into external SDRAM.

MArri.1
Associate II

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

0693W00000UnzH1QAJ.pngfor glyph 1 I get:

0693W00000UnzHBQAZ.png 

So glyphs are ok. What's going on with the library?

MM..1
Chief III

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.

MArri.1
Associate II

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.

Try check Reading 8 bit arrays from external SDRAM in STM32H7 gives corrupt data

too check signals on pins for shorts or disconnects.