Showing results for 
Search instead for 
Did you mean: 

How to solve HardFault exception loading L8 images from non memory mapped flash

Associate III

I'm working on a STM32H7B3I-DK with a 565 format frame buffer.

In my design, the Serial Flash that contents the ExtFlashSection in a standard project will not be memory mapped because I need part of it to record other data.

I followed the topics about caching bitmaps ( and ) 

In TouchGFX Designer, if I put the ’section’ part of the image to ExtFlashSection and the ‘Extra Section’ (e.g. the CLUT) in IntFlashSection everything is fine.

But if I try to put the ‘Extra Section’ in the ExtFlashSection the engine crashes on a HardFault because the library code tries to access directly the extra section in a memory mapped fashion.

Here is the state when hitting the HardFault exception


lr      0xffffffed -19

xPSR      0x21000000

ReturnAddress 0x8026bbe

LR (R14)    0x8026edb

R12      0x0

R3       0x1fe00

R2       0x14

R1        0x9001fe00

R0       0x80363d8

Return instruction:

  0x8026bbe <_ZN8touchgfx6Bitmap15getSizeOfBitmapEt+198>: ldrb r0, [r1, #3]

LR instruction:

  0x8026edb <_ZN8touchgfx6Bitmap5cacheEt+62>: mov r9, r0

I keep the linker file to have the ExtFlashSection mapped to 0x90000000 addresses so the data is loaded on debugger start but these addresses are not directly available at run time because the OSPI flash is not memory mapped as in a default TouchGfx project.

I put in bold the offending intsr/data in cpu trace. As you see, the R1 register holds the address of where is linked the _black_extra_data[] array (the CLUT of an image called ‘black’).

This fault happens before my overloaded blockCopy function is called.

Using the working linker map (with extra_ data section in internal flash), I verified that all images were copied to the cache by tracking the calls to my overloaded blockCopy function after a call to Bitmap::cacheAll() (both pixels and clut's are effectively copied to cache but this happen after the offending code !! ) 


Accepted Solutions

This library calls blockCopy() before reading the CLUT for L8 images.

View solution in original post

Chief III


This is actually a bug and we're working on a fix. Can you put the CLUTs in internal flash as a temporary fix? Otherwise i can probably provide you with a new Bitmap.o file once we fix it but before we can make a new release.


Of course, I continue working with the CLUT in internal flash, till now I’m not short in flash.
I’ll test the new release once it’s available

Okay, Pierre.

Just to be sure, your goal is to not have the CLUT in internal flash, right?


Associate III


Yes, I find it cleaner to have all image related stuff in the external memory but CLUT's are not so big so I could keep them in Internal Flash if there is no other way.



Okay, i've got a fix for it and i want to ask you to use Bitmap.o that i'm sending you in a private message soon 🙂


Which compiler are you using? Forgot to ask.

I’m on STM32CubeIDE , so GCC (On MACOS to be complete)
Associate II


I'm using STM32F429 to put touchgfx image resources in external unmapped serial flash, debugging found into Hardfault, I also refer to the official <Caching Bitmaps> and <Using Non-Memory Mapped Flash for storing images>, also just started to use touchgfx, hope you can describe what modifications to make to put touchgfx image resources in external unmapped serial flash.

Execute the code as follows to the red line 66, and you will enter hardfault: