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

[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.

[Martin KJELDSEN]

Also, thanks for trying it out so fast. I enjoy run-time ping pong to get things sorted fast 🙂

float_options := -mfpu=fpv5-sp-d16 -mfloat-abi=hard

[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 ??