STM32N655 + TouchGFX: Application Hangs When Touching a Button Widget

[Riya_L]

Hi,

I am using an STM32N655X0H3Q interfaced with an NHD-7.0-800480EF-ASXN#-CTP display that uses the FT5426G capacitive touch controller. I have created a TouchGFX screen containing a single button widget. No interactions are currently assigned to the button (I had previously tested it with a screen-change interaction, but the behaviour remained the same, so I removed all interactions and am now testing with only the button widget present on the screen).

The touch controller appears to work correctly otherwise. I can continuously poll touch events inside STM32TouchController::sampleTouch() and successfully print the touch coordinates and number of touch points when touching any area of the screen outside the button.

However, as soon as I touch the button widget, the application hangs. The button disappears and the display turns into a plain screen. At the same time, the continuous polling inside STM32TouchController::sampleTouch() stops completely, indicating that TouchGFX is no longer calling the touch sampling routine.

What could cause TouchGFX to stop polling sampleTouch() and freeze only when a button widget is touched?

[mathiasmarkussen]

Are you able to debug the project?
My best guess based on you description would be to check your stack and heap size, having them set too small can lead to weird behaviour like this.

Does this also happen if you set the button pressed asset to the same as unpressed?

[Riya_L]

Hi,
My TouchGFX pool size is 64 KB and the stack size is 63 KB. (This stack size and LTDC/TouchGFX configurations worked perfectly fine for the same application on STM32N6570-DK).
To answer your question, no, the issue did not occur when the pressed and unpressed button assets were the same.

What I noticed was that the problem seemed to be triggered by any UI invalidation. I observed the same crash when switching screens without any button interaction at all, by triggering a screen transition automatically after 50 ticks. This makes me think the issue is related to redraw activity in general rather than the button itself. Could you help me understand what might be causing this behavior? The fact that it consistently occurs on redraw operations but disappears when I switch to a single framebuffer strategy is something I'm struggling to explain.

[Riya_L]

As an update, the issue got fixed after I changed the TouchGFX framebuffer strategy from double buffering to single buffering. I made the change somewhat experimentally, so I'm still not entirely sure why it resolved the problem.

The issue still persists if I switch back to double buffering. With single buffering, the application is functional, but my actual UI is quite widget intensive and I can now see some visible glitches during screen redraws, which I suspect may be related to the single framebuffer strategy.

Could you help me understand what might be causing this behavior? Does the fact that the issue disappears with single buffering point to a framebuffer configuration, memory placement, cache, or LTDC/TouchGFX synchronization issue?

[mathiasmarkussen]

Hello,

Have you copied the linker script from the STM32N6570-DK project?

In that project, the RAM for the NPU is mapped to be used for the application. It is likely that the second framebuffer makes something link to memory that does not exist.

If you have not copied the linker script, I would take inspiration from it and place sections like it’s done in that linker script. Also set the C stack and heap in the linker script to the same values.

Make sure to update the NPU settings accordingly.

The artefacts you’re seeing in single buffering are probably tearing, which occurs if a frame is halfway rendered when the screen updates. Once the scanline passes the last rendered point, it will show the data from the previous frame instead of what should have been rendered for the bottom part of the screen. Double buffering is the solution to this, since you always have one buffer for rendering and one buffer for drawing on the screen, switching between them on the first VSYNC event after rendering is completed. It must be some UI, though, the N6 is quite powerful.

 

 

[Riya_L]

Hello,
The linker script is not identical to the STM32N6570-DK project, but it was created with the DK linker script as a reference. The MCU I'm using now is STM32N655X0H3Q, which, as far as I understand, does not include an NPU.

There is another issue that may or may not be related: I'm unable to get certain TouchGFX widgets, such as GraphLine widgets, line, and circle widgets, to appear on the actual display. They are visible on the screen in the designer, but they do not render on the target hardware. Other widgets appear to work as expected. I tried increasing the canvas buffer for the screen, but it did not make a change.
Could this behavior provide any clues as to what might be misconfigured in my setup?

[mathiasmarkussen]

Have you made sure the memory that is used for the GPU command list is non-cacheable?

Are you able to share your project?

[Riya_L]

Unfortunately, I'm not able to share the project itself. However, I've attached my MPU configuration and linker script screenshots below. Could you please take a look and let me know if anything stands out or if any of the regions used by TouchGFX should be configured differently?

 

Memory definitions in Linker Script 

MPU configs for CMDLIST

[mathiasmarkussen]

I don’t see a problem with that configuration.

It looks like you use VENCRAM and CACHEAXI as normal RAM. Have you handled that in code? In the TouchGFX project we do this:
 

static void Enable_AXICACHE_RAM_ForCore(void)
{
  __HAL_RCC_CACHEAXIRAM_MEM_CLK_ENABLE();
  __HAL_RCC_CACHEAXI_CLK_ENABLE();
}

static void Enable_VENCRAM_ForCore(void)
{
  RAMCFG_HandleTypeDef hramcfg  = {0};

  /* Power on and clock VENCRAM */
  __HAL_RCC_VENCRAM_MEM_CLK_ENABLE();
  __HAL_RCC_SYSCFG_CLK_ENABLE();
  __HAL_RCC_VENC_CLK_ENABLE();

  hramcfg.Instance = RAMCFG_VENC_RAM;
  HAL_RAMCFG_EnableAXISRAM(&hramcfg);

  HAL_SYSCFG_DisableVENCRAMReserved();
}