SSD1306 HardFault bitmap

[Rafael Zingler]

Hello.

I was able to make SSD1306 work (logo is shown, display API is working well). However, when I try to open a image from Flash memory, I'm getting a HardFault, caused by FreeRTOS memory allocator (using FreeRTOS heap4.c). The debugger shows me that the failure happens on the second call of gdispImageAlloc function (image attached): in this second call, the size to be allocated is 2 bytes. Could this be leading to a memory corruption due to unalignment? It is also important to mention that it's my fisrt time dealing with monochrome BMP's on uGFX.

When I try with a 24 bit BMP, the program doesn't stuck, and both gdispImageOpenMemory and gdispImageDraw return SUCCESS, despite of no image data being shown on the display.

Any idea of what could be wrong?

Thanks in advance.

[Joel Bodenmann]

The gfxAlloc() function is simply a wrapper macro around pvPortMalloc() if you use the FreeRTOS GOS port.

Could you tell us which architecture/platform you're running on? If it's Cortex-M based system, we might be able to get a bit more information out of this by printing out register values etc. in the hardfault handler. FreeRTOS has a resource on this: https://www.freertos.org/Debugging-Hard-Faults-On-Cortex-M-Microcontrollers.html

@inmarket Any insights into this?

[Rafael Zingler]

Hi, Joel. 

Thanks for your fast response. I'm using a LPC1768 (Cortex-M3) microcontroller and Keil uVision 5. It is the pvPortMalloc() function that is causing the fault (attached), spe cifically after updating the xFreeBytesRemaining variable.

[Rafael Zingler]

Hi all.

Defining the GDISP_IMAGE_BMP_BLIT_BUFFER_SIZE in 64 (defaults to 32) solved my problem.

[inmarket]

Looks like you might have found a bug with the FreeRTOS memory allocator.

[Joel Bodenmann]

Can you reproduce the crash by just calling pvPortMalloc(2); (i.e. outside of µGFX)?

[Rafael Zingler]

I tried calling pvPortMalloc(2); directly from my startup code and it didn't hang. 

[inmarket]

It is more likely it is caused by the sequence of Alloc's and Free's.

Another possibility is that there is a buffer overrun problem in the uGFX image code. This is also possible but unlikely as the uGFX image code is very well tested.

What strikes me as unusual here is an Alloc of just 2 bytes.

[Joel Bodenmann]

@Rafael Zingler Would you be able to share a minimum reproducible example (including the image and everything) which triggers the crash? Does running the same code on a desktop computer using the µGFX port for SDL or Win32 also result in the crash?

[Rafael Zingler]

@Joel BodenmannI didn't test the Win32 port. But yes, I will try ASAP to provide more information (including part of the code) that triggers the crash.

Thank you!

[Rafael Zingler]

@inmarketWhen the crash happens, there is a first allocation of 72 bytes, and a second one of just 2 bytes.

[Joel Bodenmann]

@Rafael Zingler Did you have any chance to check whether you can reproduce the crash on the Win32 or SDL port?

[Rafael Zingler]

Hello @Joel Bodenmann. No, I didn't do it. But as I mentioned, now it is already working (after changing the GDISP_IMAGE_BMP_BLIT_BUFFER_SIZE directive to 64).

Thanks for all your support!