2025-11-20 5:29 AM
Hello to everyone,
I'm using a custom board based over STM32H743XIH6.
I'm developing a project that need to use TouchGFX, FreeRTOS and LWIP over ethernet.
My first goal it's to be able to PING the card while TouchGFX is running, but i'm having lot of problems (hardfoults)
If I enable only TouchGFX + FreeRTOS all run well
If I enable only LWIP + FreeRTOS I can PING the card
If I enable all (LWIP-FREERTOS-TouchGFX) I have lot of problems (HardFAULTS).
Someone could share a simple project that can use all of them?
I'm using a Custom board but i could try to a NUCLEO H743ZI KIT too.
Best Regards.
Roberto
Solved! Go to Solution.
2025-12-02 6:49 AM - edited 2025-12-02 7:24 AM
Hello @Roberto C,
After thoroughly analyzing your project and debugging, I was able to isolate parts of it to test your issue. Here are my observations and recommendations:
The reason your application is not pingable is due to an overlap between the TouchGFX framebuffer and the Ethernet HEAP. In the ethernetif source file, the RX buffer count is set to 12, with each frame being 1536 bytes. This totals 18,432 bytes (approximately 18 KB). However, in your lwipopts.h file, the allocated heap size is only 16,360 bytes, which is insufficient. As a result, the compiler allocated the heap in AXISRAM at 0x2400xxxx. You resolved this by moving the framebuffer to 0x24040000.
To fix this properly, reduce the RX buffer count to 10 so the heap memory can remain at 0x30044000.
Additionally, the declaration for memp_memory_RX_POOL_base[] is missing in ethernetif.c. Although a section is declared, no variable is assigned, which may cause unpredictable behavior when integrating TouchGFX with LWIP.
#endif
#if defined ( __ICCARM__ ) /*!< IAR Compiler */
#pragma location = 0x30040200
extern u8_t memp_memory_RX_POOL_base[];
#elif defined ( __CC_ARM ) /* MDK ARM Compiler */
__attribute__((section(".Rx_PoolSection"))) extern u8_t memp_memory_RX_POOL_base[];
#elif defined ( __GNUC__ ) /* GNU */
__attribute__((section(".Rx_PoolSection"))) extern u8_t memp_memory_RX_POOL_base[];
#endif
/* USER CODE BEGIN 2 */
I also noticed that neither the Ethernet memory regions nor TouchGFX memory regions are configured in the MPU. Configuring these is recommended to prevent caching issues with Ethernet buffers and descriptors.
Lastly, you created a 256 KB memory sub-region in AXISRAM starting at 0x24000000 for the framebuffer, but this is larger than necessary. Using the formula:
Width * Height * Pixel Size = 480 * 128 * 2 = 122,880 bytes ≈ 120 KB
Dividing 122,880 by 4 gives the equivalent word size. You can declare the framebuffer as a uint32_t array and place it in the created region.
Finally, I suggest you to increase the minimum size of stack and heap in the loader file to
2025-11-20 6:17 AM
Hello @Roberto C,
It appears to be an integration issue. Could you please share where you are placing your LwIP descriptors? Additionally, please provide your STM32CubeMX .ioc configuration file and your linker file (.ld) so I can review them. A screenshot of your call stack when the application hard faults would also be helpful. Does your custom board have external SDRAM mounted for use by TouchGFX?
Best regards,
2025-11-20 6:59 AM - last edited on 2025-11-20 8:57 AM by STackPointer64
Hello STackPointer64,
Thnx for your answer.
hardfault stack:
It happen at very starting point (I suppose when freertos need to start, becouse Tim1 is used for systimer
The MX_LWIP_Init() isn't called yet, but is compiled. To avoid hard fault, i need to comment it:
// MX_LWIP_Init();
The hardfault stack:
Lwip buffer location: (from file Ethernetif.c
ETH_DMADescTypeDef DMARxDscrTab[ETH_RX_DESC_CNT] __attribute__((section(".RxDecripSection"))); /* Ethernet Rx DMA Descriptors */
ETH_DMADescTypeDef DMATxDscrTab[ETH_TX_DESC_CNT] __attribute__((section(".TxDecripSection"))); /* Ethernet Tx DMA Descriptors */
uint8_t Rx_Buff[ETH_RX_DESC_CNT][ETH_RX_BUFFER_SIZE] __attribute__((section(".RxArraySection"))); /* Ethernet Receive Buffers */
in attached file the linker file.
Best regards.
2025-11-20 7:59 AM
LwIP Rx_Buffers are supposed to be placed in a memory section named RxArraySection, according to the declaration you provided earlier. However, when reviewing your linker file, that section does not exist. Instead, it is declared as Rx_PoolSection. As a result, your pool section will default to being placed somewhere other than where it is intended.
2025-11-20 8:53 AM - last edited on 2025-11-20 8:57 AM by STackPointer64
You're right, now I correct it, but I have again the same problem,
uint8_t Rx_Buff[ETH_RX_DESC_CNT][ETH_RX_BUFFER_SIZE] __attribute__((section(".Rx_PoolSection"))); /* Ethernet Receive Buffers */
Watching the code it seems that Rx_Buff has not any reference.
Infact now, if i comment theat above raw I can compile the program.
So, maybe have I to change something in lwip configuration to let code use that buffer?...
Pls. Let me know...
Best regards.
2025-11-20 9:05 AM
Could you please attach your project so I can review it? If the project is private, feel free to send me a message privately i can provide a secure line for you to upload the project.
2025-11-20 11:29 PM
Hi,
yes it's a private project, so, pls send me instructions about how I can send it.
I'll do it later or next week, since i'll try to reduce it (but still with thre problem), so maybe it could be easier for you to check it.
Best regards.
2025-11-21 1:53 AM
Hello @Roberto C,
I have sent you a link to the ST secure file transfer platform where you can upload your project.
Best regards,
2025-11-26 5:00 AM
Hello, @STackPointer64
Last days I sent my project, to investigate the issues.
Have you any news about it?..
I continued to develop starting from that point but i'm still having troubles:
1) sometimes...randomly... (10 minuts...1 hour) i'm still having hardware fault (if i disconnect the eth cable I don't have them)
2) it seems thai if I add some other functions to my project (not concerned to Ethernet functions) I'm not able anymore to PING the card... (all the rest except Ethernet seem to run)
Best Regards.
2025-11-26 5:50 AM
Hello @Roberto C,
The issue is still under investigation. Since the attached project could not be compiled due to multiple definition errors, my progress has been delayed. I am currently investigating possible issues manually and will get back to you with updates once I have viable leads.
Best regards,