Skip to main content
MArri.1
MArri.1
Associate
October 13, 2022
Question

FontFlashSection in memory mapped SDRAM

  • October 13, 2022
  • 4 replies
  • 1990 views

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?

This topic has been closed for replies.

4 replies

MArri.1
MArri.1Author
Associate
October 13, 2022

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
MArri.1Author
Associate
October 13, 2022

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
MM..1
Chief III
October 13, 2022

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
MArri.1Author
Associate
October 14, 2022

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.

MM..1
MM..1
Chief III
October 14, 2022

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

too check signals on pins for shorts or disconnects.

Terms & ConditionsAccessibility statement