cancel
Showing results for 
Search instead for 
Did you mean: 

STM32F303VC + TouchGFX + partial framebuffer + LCD over I2C = HardFault()

KHolu.1
Associate

Hello,

I am facing some problem with updating TouchGFX application.

I need to use mono-chrome display of 128x64 resolution, driven trhough I2C, and I need to use TouchGFX to display some text using different fonts.

Hardware:

STM32F3Discovery board, with STM32F303VC MCU

IDE:

STM32CubeIDE.

TouchGFX counfiguration:

Interface = Custom

Framebbuffer Strategy = Partial Buffer

Application Tick source = Custom

Real-Time OS = CMSIS_RTOS_V2

The software is built following the guidelines from the article: https://support.touchgfx.com/docs/development/touchgfx-hal-development/scenarios/scenarios-fmc/

The problem appears when a function OSWrappers::signalVSync() is called - resulting in HardFault. By now, there are only 2 tasks active: defaultTask - loop with osDelay(1), and TouchGFX_Task.

I tried to make new application from scratch, for STM32F401RE Nucleo board (project attached), even with empty, immediately returning functions of data to LCD transfer. It also causes HardFault the same way as above described.

The functions look this:

void TGFX_Vsync(void) // tried to call in timer ISR, from other RTOS Task, and from Button EXTI
{
	HAL::getInstance()->vSync();
	OSWrappers::signalVSync();
}
 
void transmitFrameBufferBlock(uint8_t *pixels, uint16_t x, uint16_t y, uint16_t w, uint16_t h) // dummy function of transfer to LCD
{
	touchgfx::startNewTransfer();
}
 
uint8_t isTransmittingData() // dummy function unblocking framework for new transfer
{
	return 0;
}

Finally, I placed a call to TGFX_Vsync() in the EXTI button handler, made breakpoint on it and run debug session. Till the button is not pressed, all runs OK. As soon as program enters this function, there is a HardFault.

I have also another board (custom) with STM32F746, external RAM, and RGB LCD using LTDC module. I have a working TGFX project, configured to use LTDC as tick source, double bufer placed in ext. RAM, and it works fine.

I changed this particular project settings to be identical as in the Nucleo board's (except color format - left RGB565), adapted LTDC IRQ handler to be:

// TouchGFXGeneratedHAL.cpp:
    void HAL_LTDC_LineEventCallback(LTDC_HandleTypeDef *hltdc)
    {
        if (LTDC->LIPCR == lcd_int_active_line)
        {
            //entering active area
            HAL_LTDC_ProgramLineEvent(hltdc, lcd_int_porch_line);
//            HAL::getInstance()->vSync();
//            OSWrappers::signalVSync();
            // Swap frame buffers immediately instead of waiting for the task to be scheduled in.
            // Note: task will also swap when it wakes up, but that operation is guarded and will not have
            // any effect if already swapped.
//            HAL::getInstance()->swapFrameBuffers();
//            GPIO::set(GPIO::VSYNC_FREQ);
        }
        else
        {
            //exiting active area
            HAL_LTDC_ProgramLineEvent(hltdc, lcd_int_active_line);
//            GPIO::clear(GPIO::VSYNC_FREQ);
//            HAL::getInstance()->frontPorchEntered();
        }
    }
 

and added functions:

TGFX_Vsync, transmitFrameBufferBlock, isTransmittingData the same as in the Nucleo project.

I also manually set the LTDC framebuffer address to SDRAM bank.

And it works fine, no HardFault occurs.

It is also possible to copy pixel data in the function transmitFrameBufferBlock to SDRAM bank area and I can prolerly see the image on screen.

Please give hints of what can be set or written wrong in the Nucleo project (I assume that placing the same changes into Discovery project will help also).

2 REPLIES 2
Alexandre RENOUX
Principal

Hello,

You said : I changed this particular project settings to be identical as in the Nucleo board's (except color format - left RGB565)

So maybe it's the color format that makes it go into hardfault. You said your screen was monochrome so how many bits per pixel ? What are your TouchGFX settings regarding the display ?

In the Designer, you will find the Typography tab as below :

0693W000003BFKeQAO.png

You can see that the typo is 4bpp. But if you have a 1 bpp display configuration for instance, you will have a conflict. In this case, you can lower the bpp for the typos.

/Alexandre

KHolu.1
Associate

Hello and thank you for quick reply.

Originally I had set a 1bpp color format, also in typographies. The simulator project builds an runs ok.

After having noticed that VSync signal leads to HardFault, i tried making whole project from scratch (on Nucleo). It is a simple view with black background and a white circle on top, no texts etc.. Also no LCD transfer is made, only empty dummy functions that return immediately. When I started Nucleo project, I tried different formats: 1bpp, 4bpp and RGB565 (this is the attached project). It still craches... But when changed to STM32F746 platform, it runs ok - no crash.

BR

Karol​