Hi,So I'm pretty sure I've discovered a bug of varying severity related to having a bitmap image in memory and trying to add it to TouchGFX with the dynamicBitmapCreateExternal() function.I found this in our project board using a STM32H750 with 480x800 display using 16-bit colour depth. But something similar/also wrong appears to occur in the Simulator (using 4.20.0) and on a STM32F429 Disco board.I've narrowed the scenario down to the following, having tried to isolate all our code from the problem.Create a new project with empty screen. Add one image to the screen, but with no image selected.In the user code (sub-class) for the view, add some code to generate or otherwise use a bitmap image of RGB565 format. You can use a predefined one, or just generate an array of pixels to use (using touchgfx::LCD16bpp::getNativeColorFromRGB(255, 255, 255) or similar for each 16-bit pixel).Create a BMP cache using Bitmap::setCache(), and then register the bitmap using dynamicBitmapCreateExternal().Set the image widget to use the registered bitmap with dynamicBitmapCreateExternal().When drawing, various things will go wrong.On our board where I can debug, I get a hard fault with a stack trace showing a call to touchgfx::LCD16bpp::blitCopyAlphaPerPixel() from touchgfx::LCD16bpp::drawPartialBitmap(). The disassembly is dereferencing an address outside of memory space (0x10040). But this only seems to crash when the dimensions of the image cause overflow of 16-bit numbers (> 65535).On the F429 Disco, there is no crash. But generating a single colour bitmap of white/black/grey results in a background of various pixel colours - like a corrupted jpeg or something - not a sinle colour.On the simulator version of the F429 project, the simulator crashes when trying to draw the screen. GDB will not give me any help so I can't see where it is crashing. For every one of these though if instead I use a dynamic bitmap of ARGB8888 format, it always appears with no problem and exactly as I created it, e.g. solid grey or white etc.I think there's a bug in the use of the external bitmap in the RGB565 format. There's also no problem if I use an 'embedded' image (i.e. appears in bitmap_database.cpp). Can anyone assist or confirm if they've seen this work? I've attached a zip of my F429/simulator project for anyone interested enough/STM support to investigate or at least I would have done if zips were allowed.

Associate II

Question

dynamicBitmapCreateExternal() does not work for a RGB565 image

Forum|Forum|2 years ago
October 27, 2023
3 replies
2021 views

Hi,

So I'm pretty sure I've discovered a bug of varying severity related to having a bitmap image in memory and trying to add it to TouchGFX with the dynamicBitmapCreateExternal() function.

I found this in our project board using a STM32H750 with 480x800 display using 16-bit colour depth. But something similar/also wrong appears to occur in the Simulator (using 4.20.0) and on a STM32F429 Disco board.

I've narrowed the scenario down to the following, having tried to isolate all our code from the problem.

Create a new project with empty screen. Add one image to the screen, but with no image selected.
In the user code (sub-class) for the view, add some code to generate or otherwise use a bitmap image of RGB565 format. You can use a predefined one, or just generate an array of pixels to use (using touchgfx::LCD16bpp::getNativeColorFromRGB(255, 255, 255) or similar for each 16-bit pixel).
Create a BMP cache using Bitmap::setCache(), and then register the bitmap using dynamicBitmapCreateExternal().
Set the image widget to use the registered bitmap with dynamicBitmapCreateExternal().

When drawing, various things will go wrong.

On our board where I can debug, I get a hard fault with a stack trace showing a call to touchgfx::LCD16bpp::blitCopyAlphaPerPixel() from touchgfx::LCD16bpp::drawPartialBitmap(). The disassembly is dereferencing an address outside of memory space (0x10040). But this only seems to crash when the dimensions of the image cause overflow of 16-bit numbers (> 65535).
On the F429 Disco, there is no crash. But generating a single colour bitmap of white/black/grey results in a background of various pixel colours - like a corrupted jpeg or something - not a sinle colour.
On the simulator version of the F429 project, the simulator crashes when trying to draw the screen. GDB will not give me any help so I can't see where it is crashing.

For every one of these though if instead I use a dynamic bitmap of ARGB8888 format, it always appears with no problem and exactly as I created it, e.g. solid grey or white etc.

I think there's a bug in the use of the external bitmap in the RGB565 format. There's also no problem if I use an 'embedded' image (i.e. appears in bitmap_database.cpp).

Can anyone assist or confirm if they've seen this work? I've attached a zip of my F429/simulator project for anyone interested enough/STM support to investigate or at least I would have done if zips were allowed.

This topic has been closed for replies.

J

JTP1

Graduate II

Hello

Im not sure can I help you, but you can attach your project as rar- package, they are allowed. You probably need to split your package to three 5 megabyte part (select 'split to volumes' from winrar and put size bit under 5 MB). You can delete folder 'core' from \Middlewares\ST\touchgfx\lib\ to get your project to fit under 15MB since only three file is allowed here. Also folder 'bin' under \build can be deleted, it is regenerated when start simulator from tgfx designer.

Make sure that you copy your project first and then delete files from that if something goes wrong !

Br JTP

PBull

Associate II

Hello,

I stumbled today across the same issue (STM32H723). The function Bitmap::dynamicBitmapCreateExternal() doesn't work with RGB565 as parameter. I used the Bitmap loader to load a dynamic bitmap and store it in the external flash memory.

When I tried to load the image with Bitmap::dynamicBitmapCreateExternal() the application crashed (not immediately, but as soon as the image should be rendered, with a Hard-fault - PRECISERR).

There are no problems, when using Bitmap::dynamicBitmapCreateExternal() with RGB888 as parameter.

The following workaround is working for me:

Use Bitmap::dynamicBitmapCreate(), instead of Bitmap::dynamicBitmapCreateExternal()
Get the address of the dynamic bitmap
Copy the image from the external flash to the bitmap memory
Add the bitmap to the image instance

 BitmapId bmpId = Bitmap::dynamicBitmapCreate(200, 200, Bitmap::BitmapFormat::RGB565);
 uint8_t* bitmapPointer = Bitmap::dynamicBitmapGetAddress(bmpId);
 memcpy(bitmapPointer, (void const*)0x93FB0000, 200* 200 * 2);
 image.setBitmap(Bitmap(bmpId));

Greetings,

PBull

C

ChrisShawAuthor

Associate II

Thank you @PBull for confirming that I'm not an idiot or doing something wrong; good to know that somebody else has seen this.

Yep, your workaround is certainly one way to deal with it. I'm dealing with a slightly different scenario in that the image data is generated already rather than dynamically inflated, and I've chosen to force the generated image to ARGB8888 instead of RGB565 - but I like your solution too.

Thanks for the response.

Sign up

Login with SSO

Login to the community

Login with SSO