TouchGFX: Stuck in assert function of getBlockForTransfer(Rect& rect)

[Sandro_K]

Hello,

I have an STM32F777 with FreeRTOS and TouchGFX. An ST7789V2 display is controlled via SPI with a partial framebuffer. After a certain time the TouchGFX task gets stuck in the function “getBlockForTransfer(Rect& rect)” in the line “assert(state[sendingBlock] == DRAWN);”(File: FrameBufferAllocator.hpp).
Has anyone ever had something like this? How can I isolate the error why this happens?

The screenshot shows the point where the task hangs.

 

[GaetanGodart]

Hello @Sandro_K ,

Is your block size if dividable by your number of blocks in STM32CubeMX?

Can you share more of your project? Note that it is usually hard to help on hardware issues.

Regards,

[Sandro_K]

I have done further research. In this project, the LWIP stack is used to provide a webserver.

The problem only occurs when a ethernet connection is established and the client communicates with the webserver on the STM32. If Ethernet is disconnected, everything runs smoothly. I have placed the LWIP heap at the end of the SRAM memory area (see .ioc file and linker script). I am not sure if the LWIP config is ok. As I said, everything works for a while and then the error from the initial post occurs. Then the web server also stops working (probably due to the FreeRTOS priority). Mayby some data is corrupted by the webserver and this stops TouchGFX? How can I debug this?

TouchGFX always stops during the transfer of the display content. Due to the partial frame buffer, several blocks are transmitted in quick succession. TouchGFX then stops during transmission. The DMA should actually start the next transfer but TouchGFX remains stuck. The implementation of the partial framebuffer is exactly the same as in the demo projects of TouchGFX with partial framebuffer.

In the screenshot you can see the serial debug output of LWIP and the SPI output to the display. The display transmission is uncomplete, there should be some more blocks to transmit.