Hi Skullboyer,
I followed the official doc about "Caching Bitmap" and "Using non memory mapped flash" as yo did.
The steps are :
Change the linker file so only the image data is going to external flash. here is my linker file (I'm using GCC !! )
Relevant parts are here :
Extract from my STM32H7A3.ld linker file :
...
MEMORY
{
flash0 (rx) : org = 0x08000000, len = 2M /* Flash bank1+bank2 */
.... (other memory regions come here .. but are not relevants)
gui (xrw) : ORIGIN = 0x90000000, LENGTH = 4M
}
...
FontFlashSection :
{
*(FontFlashSection FontFlashSection.*)
*(.gnu.linkonce.r.*)
. = ALIGN(0x4);
} >flash0
TextFlashSection :
{
*(TextFlashSection TextFlashSection.*)
*(.gnu.linkonce.r.*)
. = ALIGN(0x4);
} >flash0
IntFlashSection :
{
*(IntFlashSection IntFlashSection.*)
*(.gnu.linkonce.r.*)
. = ALIGN(0x4);
} >flash0
ExtFlashSection :
{
*(ExtFlashSection ExtFlashSection.*)
*(.gnu.linkonce.r.*)
. = ALIGN(0x4);
} >gui
In the MEMORY table, the flash0 section is the internal flash of my STM32H7 cpu, the gui section is where the image data will be addressed by the "BlockCopy" function
The other instructions tell the linker to put "FontFlashSection" , "TextFlashSection", and "IntFlashSection" inside the CPU flash (flash0 bank) and to put "ExtFlashSection " inside the gui bank (mapped from 0x90000000)
The names of these sections are referred to by TouchGFX Designer software and thats's how you tell the Designer where to put things.
You then go to touchGfx designer to tell where your image data are stored like in the screenshot below
You have to know that an image may be cut in two parts depending on its format. That's why you have 'Section' and 'Extra Section' (surrounded by red ellipse). The 'Section' part are the actual pixels of the image and it's the only used part if your image is a non indexed format (RGB888 , RGB565, ARGB8888 ...) , with these formats the 'Extra Section' is not needed to store the image. But, if your image has an indexed format (L8_RGB565, L8_RGB888 ) these formats need a CLUT (Colour lookup table with the 256 colours used in your image) .. and this CLUT is stored in the 'Extra Section'. In the screenshot my image is an indexed L8_RGB565 and I ask TouchGFX Designer to put both pixels and CLUT in 'ExtFlashSection' (The name of the section we find in the Linker file above)
If you compile the code generated with this configuration and the modified linker file and look at the map file searching the name of your image (In my case it's Vert256) you should find lines like this ...
ExtFlashSection
0x0000000090061018 0x1fed4 TouchGFX/generated/images/src/Vert256.o
0x0000000090061018 _vert256
0x0000000090080e18 _vert256_extra_data
That means that the two parts of the image are mapped at addresses above 0x90000000 (FYI _vert256 are the Pixels, _vert256_extra_data are the CLUT)
If you make this run on your target, the GFX engine will try to load your image accessing at adresses 0x90000000 by calling the TouchGFXGeneratedHAL::blockCopy() function ... The default implementation of this function HAL::blockCopy() will simply make a memcpy of your image data (@ 0x90000000 addresses) into a RAM buffer so it will only work if the 0x90000000 address range is available with direct access ... that's not the case with 'non memory mapped' memory so this will lead to a HardFault ... So we have to change the blockCopy function to handle this case
here is my implementation in target/generated/TouchGFXGeneratedHAL.cpp :
// This function is called whenever a bitmap is cached. Must copy a number of bytes from the (non-memory-mapped) source
// to the cache.
bool TouchGFXGeneratedHAL::blockCopy(void* RESTRICT dest, const void* RESTRICT src, uint32_t numBytes)
{
// If requested data is located within the memory block we have assigned for ExtFlashSection,
// provide an implementation for data copying.
uint32_t offset = (uint32_t) src;
if (offset >= 0x90000000 && offset < 0x91000000)
{
// Get image data from SNOR flash
offset -= 0x90000000;
flashDirectRead(offset, (uint8_t*) dest, numBytes);
return true;
}
else
{
// For all other addresses, just use the default implementation.
// This is important, as blockCopy is also used for other things in the core framework.
return HAL::blockCopy(dest, src, numBytes);
}
}When blockCopy wants to get data from 0x90000000 and above we do not call the default 'memcpy like' default HAL-blockCopy but, instead, call a specific function to read the requested data from the external flash (in my case flashDirectRead() will do his job.) .. Of course, that supposes that the image data where stored in the external memory by some means before you run the program 😉
There is one thing left to say .... my example will not work with the official libtouchgfx.a but only with the one Martin built yesterday. That's because the official library has an issue with the copy of indexed images (the ones using CLUT's). To make my sample work you have to either not use indexed image format ... (RGB565 / RGB888) as those images will not access the 'extra data' section (You will not find the _vert256_extra_data in the map file) ... or ask touchGFX Designer to put this 'extra data' in a memory mapped area selecting 'IntFlashSection' in the combo 'Extra Section' of the image.
In this last case the map file should show something like :
ExtFlashSection
0x0000000090061018 0x1fe00 TouchGFX/generated/images/src/Vert256.o
0x0000000090061018 _vert256
...
IntFlashSection
0x000000000806ef4c 0xd4 TouchGFX/generated/images/src/Vert256.o
0x000000000806ef4c _vert256_extra_data
Showing that the extra part (the CLUT) is now placed in the Internal CPU Flash ans thus can be accessed directly by the library avoiding the HardFault
Hoping I did not forget something important 😉
