Why engine hangs if I have a background image that do not have default pixel format ?

[PJEN]

I'm trying TouchGFX on a STM32H7B3I-DK board and managed to have it running with RGB565 pixel format. The first screen has an image has background and one image, one text area and one button on it. If the background image is specified with the default RGB565 format everything is fine but if I make it L8_RGB565 the drawing engine hangs and never return from backPorchExited() in TouchGFXHAL::taskEntry() function.

When using default RGB565 for background image I may change the image with a SetBitmap using an L8_RGB565, I may also switch to a second screen that has a L8 background image, so the problem is limited to the setup of the first screen.

Has someone encountered the same problem, or did I forget some initialisation of CLUT or ...

[Martin KJELDSEN]

Hi Pierre,

Just wanted to let you know that i have your project and have done a quick test. TouchGFX is not even started (for me) when your project hard faults (at MX_DMA2D_Init). Will try to investigate.

/Martin

[PJEN]

Hi Martin,
Strange that you do not have the same behaviour !!
This project is directly coming from TouchGFX Designer 4.13.0. You can re-create it in a few minutes.
I just selected the H7B3-DK platform and the Blank template, added this « shade of green » image on « screen1 » and a button then pressing « Run Target » to compile and upload to the target.
The only modification to the sources generated by the Designer was to correct the VOLTAGE_SCALE value to 0 instead of 2 to have the CPU running at 280MHz , and ,of course, changing the image format to L8 !!
Did you try with the image reset to default format,( it should be running fine in this case ) ?
BR
Pierre

[Martin KJELDSEN]

Hi,

I can verify that there's an issue if you don't change voltage scaling. This is seriously strange. Are you using a new board? My old one at the office works fine, but this new board i just unpacked from the plastic doesn't - Even with powerscaling the colors are not correct for e.g. RGGB888.

I'm going to do some more digging on this today. ST sometimes changes components and we have to be on the ball.

[PJEN]

Hello,
My board has been ordered about 5 or 6 weeks ago so it’s rather new.
For the voltage scaling, what is ’strange’ is that your old board is running because with VOS2, the CPU is not supposed to run above 160MHz sysclk.
In the project, the clock is programmed full speed (280MHz) , so it is mandatory to set the voltage scaling to VOS0 value.
It seems that the CPU mounted on your ‘old’ board is kind of a pearl able to run at 280Mhz with a lower voltage.
About colors on your new board, it’s maybe a production problem on this board ??… but it reminds me of a behaviour I experienced when playing around with the board …
I’ve been in a situation where the background image has a ‘black hole’ in the middle where normally it must be full green !!
I first suspected a problem in the code I was working on (not related to the screen !!) so I’ve been removing code , re-flashing several times without success and, suddenly, this behaviour disappeared after a complete power off and SWD disconnect.
If you see the same color mismatch (for me it was a black disk of about 1cm diameter just where the green color is nearly saturated in the image, quite close to the center of the screen) … just like if the CLUT programming was wrong !!
If it’s the same on your side that could mean that it lacks some initialisation in the startup code !!??
Pierre

[PJEN]

Hi Martin, Beside the current issue (which I can workaround using a ’splash screen’ built without L8 encoded background) I’m facing a little more annoying problem with L8 images. 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 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 available at run time because the OSPI flash is not memory mapped as in a default project. I put in red 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 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 !! ) BR, Pierre