RGB image compression memory fault

[PontusL]

Hey,

I am trying out the new RGB image compression in TGFX 4.24 and are having some issues. My program compiles fine without any compression.

I have only turned the feature on in TouchGFX Designer and generated code. Is there something else I am missing? It does no seem like it after reading the documentation.

This is the resulting stack

 

 

MemManage_Handler() at stm32h7xx_it.c:112 0x2dc
<signal handler called>() at 0xffffffed
touchgfx::LCD32bpp::DecompressorRGB_QOI::blitCopyARGB8888() at 0x9015c560
touchgfx::LCD32bpp::drawPartialBitmap() at 0x9015d9da
touchgfx::Image::draw() at Image.cpp:37 0x90027090
touchgfx::Screen::JSMOC() at 0x901556ec
touchgfx::Screen::JSMOC() at 0x90155696
touchgfx::Screen::JSMOC() at 0x90155696
...

Edit: I am using external flash

 

 

 

[GaetanGodart]

Hello @PontusL ,

 

Can you specify what hardware you are using?

Have you also updated the TouchGFX Generator pack in STM32CubeMX?

Can you give us steps to reproduce or send your project?

 

Regards,

[PontusL]

Hello,

I am using custom hardware based around an STM32H750 with sdram for the framebuffer and external flash memory for the code and assets. LCD-LTDC display and I have ChromART enabled. I use FreeRTOS.

Been running 4.22.0 for a couple of months without issues. Updated to 4.24.0 when launched and have not had any issues here either.

Yes, I have updated the TouchGFX Generator pack in STM32CubeMX.

The steps to reproduce the issue is simply to:

1. Go into TouchGFX Designer and go to Images
2. Change the image format, for any image, to ARGB888 and compression to Yes (I have Default as None for RGB Compression in Default Image Configuration)
3. Generate new code in the designer and compile. 
4. The screen will freeze and the program will result in the memory fault handler when the GUI tries to show the image on the screen. Seems to be related to 

   touchgfx::LCD32bpp::DecompressorRGB_QOI::blitCopyARGB8888()

 

//Pontus

[GaetanGodart]

Hello @PontusL ,

 

I have used the STM32H750B-DK board to reproduce your steps:

1. Create a new project from TouchGFX Designer, add an image, set the image asset to one of the free assets from the TouchGFX Stock. I have also added a simple white box and made it move 1 pixel down every tick until it reach the bottom of the screen in which case it goes back to the top of the screen.
2. Change the image format to ARGB8888, set compression to "Yes".
3. Generate code and flash on target.
4. I see the image properly and the box keeps on going down forever, it never crashes.

 

I think the issue comes from  your custom board setup which is hard for me to debug.

 

Maybe you ca try to go deeper into understanding which functions makes your GUI crash, which line of blitCopyARGB8888(), which function calls blitCopyARGB8888(), etc.

 

Also, does your image have transparency?

 

Regards,

[PontusL]

Hello Gaetan,

Thanks for taking the time to look into my issue.

Yes, I suspect it relates to my external flash which makes it very hard for you :). I have some more details about the function calls leading up the the crash in my first post, and I hoped it would maybe be something minor easy to spot based on this. 

The image have transparency. But I have also tried with an image without transparency, using RGB888, which results in the same behavior.  I will have a deeper look when I have time! Could possibly also try to import my project to my STM32H750B-DK to try and spot differences. 

 

Thanks,

Pontus

[GaetanGodart]

Hello @PontusL ,

 

I will have a deeper look when I have time! Could possibly also try to import my project to my STM32H750B-DK to try and spot differences.

I can try your GUI on my board if that can help

Maybe have a look at this post where another user also had issue with external memory and with a blitCopy function (not related to compression thought).

Do you only have your issue when compressing or does it happen on uncompressed images too?

 

Regards,

[Flemming Gram CHRISTENSEN]

Hello PontusL

Coming back to this question for future reference.

The decompression of ARGB8888 uses two small scratch buffers.

The are called scratchBufferA and scratchBufferB.

They are in separate segments with names TouchGFX_ScratchbufferA, TouchGFX_ScratchbufferB.

These buffers are accessed by DMA2D and can therefore not be located in DTCM or SRAM4. DMA2D cannot access these memory regions.

Move the buffers to normal AXI SRAM.

Best Regards