Ethernet Communication Unstable After Integrating TouchGFX on STM32H743 – Suspecting AXI Bus Conflicts

[jumman_JHINGA]

Hello ST Community,

I'm currently developing a project on STM32H743 using TouchGFX 4.25.0 (RGB LTDC interface, framebuffer in external 16MB SDRAM) and LWIP + FreeRTOS (TCP client mode over Ethernet RMII). Everything works fine when TouchGFX is not included. However, after adding TouchGFX to the project, I'm facing strange Ethernet instability.

---

:magnifying_glass_tilted_left: Observations:

1. Without TouchGFX:

   • TCP Client connects to the server reliably.

   • No reconnection or data loss observed.

   • Using recv() with flags = 0 works flawlessly for long durations.

2. With TouchGFX + LTDC + DMA2D:

   • Frequent TCP reconnections start occurring.

   • Happens especially when using lwip_select() + recv() mechanism.

   • If I skip lwip_select() and use direct recv() with flags = 0, reconnections stop, but after some time communication lags or stalls.

---

:light_bulb: Hypothesis:
I suspect the problem lies in AXI bus contention between:

• LTDC/DMA2D accessing external SDRAM (for framebuffer)

• Ethernet DMA accessing DTCM/SRAM or other AXI slaves

• Possibly QSPI access if active for bitmap cache

I'm considering using AXI PMU (Performance Monitoring Unit) to measure:

• Bus latency

• AXI master stalls

• Transaction overlap

However, documentation on AXI PMU in STM32H7 context is scarce, especially under FreeRTOS + TouchGFX + LwIP.

---

:question_mark: Questions to Community:

1. Has anyone faced similar TCP instability or lag after enabling TouchGFX or DMA-heavy peripherals?

2. Can AXI PMU registers be monitored in runtime to measure bus load/stalls in FreeRTOS?

3. Any suggestion to prioritize Ethernet DMA transactions on AXI bus?

4. Can DMA2D or LTDC be throttled or delayed to reduce congestion?

---

:package: Configuration:

• MCU: STM32H743II

• TouchGFX: 4.25.0 (LTDC RGB interface)

• SDRAM: 16MB at 0xD0000000 (double-buffered framebuffer)

• QSPI Flash: For external bitmap assets (W25Q128)

• FreeRTOS: Default settings (preemptive)

• Ethernet: LwIP TCP Client using RAW API

• Compiler: STM32CubeIDE + GCC

---

I'm open to any insights, workaround ideas, or experiences. I’d also be happy to share code structure or bus matrix settings if needed.

Thanks in advance,
Jumman Jhinga

[mbarg.1]

Ethernet in current STM32Cube implementation requires top priority access not to crash ( and I found data streams capable of crashing it also with STM examples) - adding other peripherals will slow response times by sure and that could be one reason of your blues.

What you suspect (internal blocks) @480Mhz clock have limited impact, SDRAM use a lot of bw more than display driver; i would focus on Ethernet implementation before scaling to low level hw.

[jumman_JHINGA]

@mbarg.1 Thanks for your input.

Yes, I'm already managing priorities accordingly:

HAL_NVIC_SetPriority(ETH_IRQn, 5, 0); // High priority for Ethernet 
HAL_NVIC_SetPriority(QUADSPI_IRQn, 6, 0); // Medium priority 
HAL_NVIC_SetPriority(DMA2D_IRQn, 7, 0); // Lower priority for graphics

im using System clocks as follow:

• CPU Frequency: 240 MHz (set via CubeMX)

• LTDC Pixel Clock: 60 MHz

To monitor runtime behavio im calculating time using DWT registers:

• TCP latency (send → receive): ~500 µs to 1 ms

• Communication thread execution: ~12–200 ms depending how much over-all delay im giving, exactly its showing.

• CPU load: ~93–97% in normal operation

These metrics remain stable unless packets are delayed or missed — then latency and thread timing increase accordingly.

[Guillaume K]

According to RM0433, on STM32H743 the ethernet has direct access to AHB SRAMs only.

so try to put ethernet descriptors and buffers on AHB SRAMs (0x3000 0000, ...) and not AXI SRAM, nor DTCM.

 

[MStackDev_376]

Hi jumman_JHINGA,

As mbarg.1 pointed out, it's likely that the issue revolves around the Ethernet implementation.

It could be because a complex networking stack like lwip might become sensitive to increased system load from peripherals like TouchGFX. This could result in the issues you are noticing.

If the solution from Guillaume of placing the descriptors in other memory section does not work, I would suggest you to test your system with a more lightweight Ethernet implementation.

As an alternative to lwip, you could try this example  I've put together. It uses the Mongoose Networking library, which is a self-contained networking library designed with a minimal footprint and a focus on stability in embedded environments. The example is a CubeIDE project running a simple web-server powered by Mongoose in the FreeRTOS environment. You could then use this example and build upon it by integrating your application, including TouchGFX and notice if there are any issues. If everything runs OK, it would confirm that the issue is within the STM32Cube Ethernet implementation and not other clocks or bus conflicts issues.

Hope this helps you solve the problem!

[jumman_JHINGA]

Guys i created same project(TCP + TouchGFX) on diffrent STM32F746IGT board and got diffrent result. 

I’m ran TouchGFX GUI with TCP communication on both STM32F746 using the exact same codebase.

Results:

• On STM32F746, it runs perfectly fine for 60+ minutes. No disconnections, no display freeze, no missed data.
  Setup:

  • HSE clock

  • D-Cache disabled (was causing “undefined network” when enabled)

  • DMA2D in memory-to-memory mode

  • LTDC at 45 MHz

  • CPU at 216 MHz

• On STM32H743, frequent TCP disconnections happen.
  Setup:

  • HSI clock ( I faced Display Flickering issue with HSE earlier)

  • D-Cache enabled

  • DMA2D in blending mode

  • LTDC at 60 MHz

  • CPU at 240 MHz

  • No Mongoose stack — just raw sockets

So my question is:

Is this an issue with the STM32H743 hardware itself (bus conflict, cache behavior, etc.)? Or could it be some misconfiguration on my side?

[jumman_JHINGA]

Instead of FreeRTOS now im using Azure RTOS and every things working fine. No disconnections, no display freeze, no missed data.