STM32F103 + FreeRTOS + uGFX + BMP = HardFault

[Insecticide]

Hello,

I have some troubles with displaying BMP monochrome picture on display. I use the ugfx library with the 128*64 display (ssd1306 controller) and  STM32F103CBT6; FreeRTOS uses HEAP4 memory manager. uGFX starts working in a dedicated task (uGFX init) and  LOGOis displayed. In process task I try to drawing image (BMP 24*24 pixels).

void displayPainter::vPrintScreen(uint32_t numScreen, screenPayload_t& data)
{
		switch (numScreen)
		{
		case 0:
		{
			static gdispImage myImage;
			gdispImageOpenFile(&myImage, "gasoline.bmp");
			gdispImageDraw(&myImage, 0, 0,  myImage.width, myImage.height, 0, 0);
			gdispImageClose(&myImage);
		}
		break;
		case 1:// Gazoline for station in km

		break;
		case 2:// Error menu enter

		break;
		case 3://Error entity

		break;
		case 4://Eraze error

		break;
		case 5://No eraze error

		break;
		default:
		//Startup LOGO and TEST
		break;
		};


}

But code breaks into the HardFault Handler in gdispImageOpenFile() function (in allocating memory procedure for priv->palette value). This error occures with images, strings and LOGO are drawn correctly.

I tryed to insert Image drawing code to uGFX initialization task. Same error  occured.

What's the matter? What am I doing wrong? Thanks in advance/

[inmarket]

It sounds like something is going on with your memory allocator.

The uGFX logo is actually not an image. It is a series of rectangles drawn on the screen. It is therefore possible that this call is the first call to the memory allocator. That is something you can test and debug.

The other possibility is that the image is corrupt somehow. This is easy to check by looking at the parameters that are going to be used by the palette allocation and seeing if they are reasonable. 

Another possibility is that you have stack checking turned on in your compile. Many memory allocators are assumed to be single threaded and will hard-fault if running on a thread on a stack other than the main threads. Given you are running FreeRTOS which is multi-thread aware you can assume that its allocator is multi-thread capable however still check that you are compiling without stack checking turned on.