Blockcopy not called when fetching Extra Data in ExtFlashSection

[Dadigno]

I'm working on a custom STM32U5 board with TouchGFX. The board features an external NOR flash memory used for storing the ExtFlashSection (as documented here).

In my project testing, I aim to display a simple black and white image with a transparent area. Initially, I configured TouchGFX Designer to place both the "Section" and "Extra Section" within the internal flash (IntFlashSection), and everything functioned as expected. However, my application necessitates storing media files in the external memory.

To achieve this, I successfully linked the ExtFlashSection to the external NOR flash. Subsequently, I modified the positions of both the "Section" and "Extra Section" from IntFlashSection to ExtFlashSection.

after compilation this my external memory:

When running the code, a hard fault occurs. This is likely due to TouchGFX attempting to directly fetch data from external memory during the loading of the "Extra Section" data, instead of using the BlockCopy function.

This is the Trace:

And these are the registers: 

I came across this post and suspected it might be related to a known TouchGFX bug. I decided to move only the extra data to the IntFlashSection, which initially resolved the issue. However, when I tried changing the background image from bg_1.png to bg_2.png, a hard fault occurred again....here there are trace and registers

This time r1 is contains the base address for Extra Section of bg_2 in internal flash. So memory access should be ok....

What is the difference between bg_1.png and bg_2.png that could be causing this problem?

I would appreciate any suggestions or hints to resolve my problem.

[GaetanGodart]

Hello @Dadigno ,

I was running out of ideas so I sent this thread to @LouisB .

Have you tried to cache your bitmaps like JTP1 proposed?
Here is another user who had an issue with caching bitmaps so he shared his code to cache bitmaps, you could use it as a starting point : cache-memory-seems-to-crash/td-p/665540 

Regards,

[Dadigno]

Hi @GaetanGodart, 

The documentation say "In order to use the bitmap caching feature, you need to first provide a bitmap cache configuration to TouchGFX, and secondly (in some cases) to provide a hardware specific implementation of the BlockCopy function for reading data from your external storage."

Therefore, I think the problem remains since blockcopy must still be called to load media from external storage.

Regards

[GaetanGodart]

I asked the team in charge of the framework (who know better about this kind of issues).

The copyBitmapToCache function calls blockcopy so caching your bitmaps could solve the issue. I think it is worth the try as we don't have other lead so far.

Regards,

[MM..1]

Ofcourse, but designer generator dont support this type images. 

[Dadigno]

Hi @GaetanGodart,

Finally, we've achieved some results! Caching bitmaps seems to be the only way to load and show image with transparency from not mapped external memory. Now, blockcopy is called once at caching time, and images with transparency are displayed correctly.

This again proves that the setup is correct, but the core has a problem loading images with transparencies when the cache is not used.

Unfortunately I don’t want to use the cache ( not always ). So this is not the final solution for me.

Regards

[MM..1]

Part of docu

as i write now unsupported.

[Dadigno]

Hi @MM..1 ,

I'm sorry but I do not get your point.

I want to load media from an external flash memory in non-mapped memory mode ( docu ) without cache, but an exception occurs when I use images that contain transparencies.

[MM..1]

OK and i and docu say you cant. Because all lib code is optimized to load images from addressable memory.

Nothink more. Then for non mapped is required precache image to addressable arrea.

Maybe you can create special widget external image and draw your way...

Actual latest version support only this LCD16bppSerialFlash | TouchGFX Documentation

[Dadigno]

Hi @MM..1 ,

So, you're saying that the fact that blockCopy is called even when I'm not using the cache is a behavior not foreseen by the documentation? This would explain the strange behavior in my setup...

If I don't want to use the cache, do I have to use the External Data Reader interface? Correct?

Regards

[GaetanGodart]

Hello @Dadigno ,

Have you been able to try to precache images as @MM..1 suggested?
Did you found another solution that better suits your needs?

Regards,