STM32F303VC + TouchGFX + partial framebuffer + LCD over I2C = HardFault()
- July 24, 2020
- 2 replies
- 1769 views
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).
