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

[PJEN]

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 (https://support.touchgfx.com/docs/development/ui-development/touchgfx-engine-features/caching-bitmaps and https://support.touchgfx.com/docs/development/ui-development/scenarios/using-non-memory-mapped-flash ) 

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

EXEC_RETURN (LR):

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 !! ) 

[Martin KJELDSEN]

Hi,

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.

/Martin

[PJEN]

Hi,
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
Thanks,
Pierre

[Martin KJELDSEN]

Okay, Pierre.

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

/Martin

[PJEN]

Hi,

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.

BR,

Pierre

[Martin KJELDSEN]

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 :)

[PJEN]

�?

[skullboyer]

Hi,PJEN

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:

[skullboyer]

I put the following xx_Section in external serial flash by loading the algorithm

Modify the blockCopy() interface with reference to the official documentation as follows

I don't know what else I need to change, looking forward to your guidance, thanks!

[PJEN]

Hi Skullboyer

I followed the same rules given in the documentation for the same results ;-).

I'm waiting for a solution from ST as it seems to be an issue in the TouchGfx library.

A patch should come soon ....

[skullboyer]

Oh�?You mean the methods presented according to the official documentation won't work?

[PJEN]

Hi,

The method from documentation is working with non indexed image formats (those that do not rely on CLUT's).

If you want to use indexed color images, you have to keep the 'extra' section in internal flash so the library can address the clut with a pointer.

Do this in the TouchGfx designer in the 'image' setup screen like in this screen shot, and map the ExtFlashSection only in the external (non memory mapped) flash.

Keep the IntFlashSection in the internal cpu flash.

To have this working, 'extra section' must be kept in 'IntFlashSection' because this section will be addressed with a pointer in the library !!!

And also, in your linker file, I see you placed 'FontFlashSection' and 'TextFlashSection' in your external memory ... not sure that it is working !!

I've seen in the documentation that the fonts may also be placed in a non memory mapped external flash, but never tried it.

Maybe you could try to place those Font and Text sections in the CPU flash memory (if it's not too big) , so only the images (ExtFlashSection) will go in your external flash

[Martin KJELDSEN]

We're coming up with a patch for this, yes. PJEN is right. I'm sending him a patch to see if this fixes the issue for him so that it will call blockCopy() before reading the CLUT data.

/Martin

[Martin KJELDSEN]

Thanks @PJEN​ for a nice find. I've built it using the same arm-gcc version i could find in CubeIDE 1.3.0 (

Here's the patched Bitmap.o file - try it out and let me know.

[PJEN]

Hi,

Downloaded the Bitmap.o but it seems to have been compiled without hard-fpu support ... I forgot to mention that I use the libtouchgfx-float-abi-hard library.

It's rather big work for me to re-target my current development to soft-float as some parts of my project currently rely on hard float support.

If it's easy for you to re-compile with '-mfpu=fpv5-d16 -mfloat-abi=hard' compiler flags .. I would prefer ;) .. otherwise I'll have to comment out big part of my code to be able to compile without FPU

thx,

Pierre

[Martin KJELDSEN]

Allright! I figured i'd just give it a go without asking more questions :D Maybe i'd hit the jackpot first try.

[PJEN]

I tried adding the Bitmap.o to the object list but the linker still use the 'Bitmap.o' found in the .a file :(

So, I deleted the Bitmap.o from the library with arm-none-eabi-ar tool and adding your new Bitmap.o , either linking the .o directly or adding it to the lib ...

But the linker complains as if the functions where not found ... Any suggestion ??