How to fix this strange behaviour on a STM32H750 touchgfx run from SDRAM
We are trying to get touchgfx run on a custom STM32H750XB board. Currently all is run out of SDRAM, and seems to go well but with the characters we hit a problem.
With the current test case we want to show text “abcdefghijklmn�? on a simple startupscreen.
In the HAL layer, STM32H7DMA::setupDataCopy(const BlitOp& blitOp) is called for every character that must be printed. But during debugging we see a strange behavior.
The first character 'a' is printed correctly. But the next is not. In setupDataCopy we see that the blitOp.pSrc is set to the start of the font table (so pointing back to char 'a').
But blitOp.nSteps and blitOp.nSteps.nLoops are the correct ones for char 'b'.
And the strange thing is that all the odd chars are correct and the even chars have this strange behavior. (odd/even as index in the font table)
so we get “a#c#e#g#i#j#m#�? where the # is the char 'a' printed on the size of the mentioned char.
And here the font table that is used.
KEEP extern const touchgfx::GlyphNode glyphs_verdanab_20_4bpp[] FONT_TABLE_LOCATION_FLASH_ATTRIBUTE =
{
{ 0, 0x0061, 12, 11, 11, 0, 13, 0, 0, 0x00 },
{ 66, 0x0062, 13, 15, 15, 1, 14, 0, 0, 0x00 },
{ 171, 0x0063, 12, 11, 11, 0, 12, 0, 0, 0x00 },
{ 237, 0x0064, 13, 15, 15, 0, 14, 0, 0, 0x00 },
{ 342, 0x0065, 13, 11, 11, 0, 13, 0, 0, 0x00 },
{ 419, 0x0066, 9, 15, 15, 0, 8, 0, 0, 0x00 },
{ 494, 0x0067, 13, 15, 11, 0, 14, 0, 0, 0x00 },
{ 599, 0x0068, 12, 15, 15, 1, 14, 0, 0, 0x00 },
{ 689, 0x0069, 5, 15, 15, 1, 7, 0, 0, 0x00 },
{ 734, 0x006A, 8, 19, 15, -1, 8, 0, 0, 0x00 },
{ 810, 0x006B, 13, 15, 15, 1, 13, 0, 0, 0x00 },
{ 915, 0x006C, 5, 15, 15, 1, 7, 0, 0, 0x00 },
{ 960, 0x006D, 19, 11, 11, 1, 21, 0, 0, 0x00 },
{ 1070, 0x006E, 12, 11, 11, 1, 14, 0, 0, 0x00 }
};
And the result for “abcdefghijklmn�? on the LCD

And the result for “aabbccddeeffgghh�? on the LCD

Touchgfx 4.12.3 is used to generate the code.
The libtouchgfx.a lib we have copied from a demoboard build (STM32H743I_EVAL) that we have running here.
