cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H745ZITx FreeRTOS + LwIP TCP Server accept() Issue

KemalUzgoren
Associate III

Hello,

I am working on the STM32H745ZITx platform and using both CM7 and CM4 cores with FreeRTOS. I am trying to run a TCP server on the CM7 core using LwIP.

However, when I call the accept() function, the system seems to hang. Specifically, after accept() is called, none of the tasks on the CM7 core continue to run — it appears as if the RTOS scheduler has crashed or is blocked.

I have reviewed the example from this repository:

STM32H745_Nucleo_M7_ETH 

and followed the STM32H745_Nucleo_M7_ETH project structure closely.

Do you have any suggestions or guidance on what else I should check? Could this be related to interrupt priority, improper memory configuration, or something else I may have overlooked?

I would appreciate any help or insights you can provide.

Best regards,
Kemal UZGOREN

1 ACCEPTED SOLUTION

Accepted Solutions
KemalUzgoren
Associate III

The problem was caused by using the Socket API (socket(), accept()) in an RTOS environment. STM32 examples (like STM32H745_NUCLEO_M7_ETH) use Raw TCP API (tcp_new(), tcp_accept()) instead.

After switching to the Raw TCP API, the accept callback started working correctly.

Hope this helps!

View solution in original post

4 REPLIES 4
KemalUzgoren
Associate III

I have found a detailed guide about setting up Ethernet with LwIP on STM32H7 series MCUs on the ST Community here:

How to create a project for STM32H7 with Ethernet and LwIP stack working  

I will carefully follow the instructions provided in this article, particularly checking interrupt priorities, memory placement configurations, and cache settings as recommended.

I'll update once I test these configurations.

Regards,
Kemal UZGOREN

KemalUzgoren
Associate III

Hi, 

I am developing a TCP server application using STM32H745ZITx microcontroller. Both CM7 and CM4 cores are active in the system and FreeRTOS is running. Ethernet operations are done in the CM7 kernel. However, after the accept() function is called, the related task does not run again; there is a task crash in the system. I cannot find the source of this problem.

1. MPU settings

Screenshot 2025-06-19 121145.pngScreenshot 2025-06-19 121211.png

2. LWIP Heap Settings

Screenshot 2025-06-19 161917.png

Problem Summary:

       - socket(), bind(), listen() functions work fine.
       - When accept() is called, the task does not run again.
       - The prvCheckTasksWaitingTermination() function of FreeRTOS is called and the task is deleted.
       - Linker, MPU and LWIP configurations are according to STM's examples.
       - No compilation error or overflow warning is received.

At this point, what could be the cause of the task crash after accept()? I think it could be caused by MPU, LWIP stack, or FreeRTOS configuration, but I could not pinpoint it.
If anyone has encountered a similar situation or can give an opinion on this issue, I would appreciate your support.

Best regards,
Kemal UZGOREN

 

In addition

3. Linker Script for CM7


In the linker script I defined special sections for ETH DMA descriptor and RX buffer. I also set the starting address of RAM_D2 to 0x30020000 and limited its size to 160K to avoid conflicts with the M4 core:

/* Memories definition */
MEMORY
{
RAM_D1 (xrw) : ORIGIN = 0x24000000, LENGTH = 512K
FLASH (rx) : ORIGIN = 0x08000000, LENGTH = 1024K /* Memory is divided. Actual start is 0x08000000 and actual length is 2048K */
DTCMRAM (xrw) : ORIGIN = 0x20000000, LENGTH = 128K
/* ETH_CODE: change offset & reduce size of RAM_D2 to not collide with M4 */
RAM_D2 (xrw) : ORIGIN = 0x30020000, LENGTH = 160K
RAM_D3 (xrw) : ORIGIN = 0x38000000, LENGTH = 64K
ITCMRAM (xrw) : ORIGIN = 0x00000000, LENGTH = 64K
}

Add lwip_sec for DMA descriptors and RX buffers as follows:

/* ETH_CODE: add placement of DMA descriptors and RX buffers */
.lwip_sec (NOLOAD) :
{
. = ABSOLUTE(0x30040000);
*(.RxDecripSection)
. = ABSOLUTE(0x30040060);
*(.TxDecripSection)
. = ABSOLUTE(0x30040200);
*(.Rx_PoolSection)
} >RAM_D2

KemalUzgoren
Associate III

The problem was caused by using the Socket API (socket(), accept()) in an RTOS environment. STM32 examples (like STM32H745_NUCLEO_M7_ETH) use Raw TCP API (tcp_new(), tcp_accept()) instead.

After switching to the Raw TCP API, the accept callback started working correctly.

Hope this helps!