STM32F7 lwIP Ethernet [FreeRTOS] - TxPktSemaphore not given

[leoneln]

I'm developing a device that works as a modbus slave over TCP/IP. For this application I'm using FreeRTOS with CMSIS-v1 and LwIP. The problem occurs sometimes when I disconnect the master (a PC with modbus poll), then the code stucks waiting for a semaphore (TxPktSemaphore) inside the function low_level_output() on ethernetif.c

Here is the part of the code where the ejecution keeps waiting forever a semaphore (line 8).

TxConfig.Length = p->tot_len;
 TxConfig.TxBuffer = Txbuffer;
 TxConfig.pData = p;
 
 pbuf_ref(p);
 
 HAL_ETH_Transmit_IT(&heth, &TxConfig);
 while(osSemaphoreWait(TxPktSemaphore, TIME_WAITING_FOR_INPUT)!=osOK)
 
 {
 }
 
 HAL_ETH_ReleaseTxPacket(&heth);
 
 return errval;

In addition, I attach a wireshark capture when the master (10.8.51.2) request the end of the connection and the problem doesn´t occur:

 

But when the problem occasionally occurs, there is a RST:

Please consider in both captures that I have more than one connection at the same time between master and slave, that's the reason there is activity after the desconnection (belongs to other ports

).

Thanks in advance.

[EOzde.1]

Hi,

What version of FreeRTOS you are using V1 or V2 ?

[leoneln]

Hi, thanks for replying.

I'm using CMSIS-v1 and FreeRTOS Kernel V10.2.1.

I show my FreeRTOS config below:

#define configENABLE_FPU 0
#define configENABLE_MPU 0
 
#define configUSE_PREEMPTION 1
#define configSUPPORT_STATIC_ALLOCATION 1
#define configSUPPORT_DYNAMIC_ALLOCATION 1
#define configUSE_IDLE_HOOK 0
#define configUSE_TICK_HOOK 0
#define configCPU_CLOCK_HZ ( SystemCoreClock )
#define configTICK_RATE_HZ ((TickType_t)1000)
#define configMAX_PRIORITIES ( 7 )
#define configMINIMAL_STACK_SIZE ((uint16_t)128)
#define configTOTAL_HEAP_SIZE ((size_t)15360)
#define configMAX_TASK_NAME_LEN ( 16 )
#define configUSE_16_BIT_TICKS 0
#define configUSE_MUTEXES 1
#define configQUEUE_REGISTRY_SIZE 8
#define configUSE_PORT_OPTIMISED_TASK_SELECTION 1
/* Defaults to size_t for backward compatibility, but can be changed
 if lengths will always be less than the number of bytes in a size_t. */
#define configMESSAGE_BUFFER_LENGTH_TYPE size_t
 
/* Co-routine definitions. */
#define configUSE_CO_ROUTINES 0
#define configMAX_CO_ROUTINE_PRIORITIES ( 2 )
 
/* The following flag must be enabled only when using newlib */
#define configUSE_NEWLIB_REENTRANT 1
 
/* Set the following definitions to 1 to include the API function, or zero
to exclude the API function. */
#define INCLUDE_vTaskPrioritySet 1
#define INCLUDE_uxTaskPriorityGet 1
#define INCLUDE_vTaskDelete 1
#define INCLUDE_vTaskCleanUpResources 0
#define INCLUDE_vTaskSuspend 1
#define INCLUDE_vTaskDelayUntil 0
#define INCLUDE_vTaskDelay 1
#define INCLUDE_xTaskGetSchedulerState 1

[Semer CHERNI]

Hello @leoneln​ 

First let me thank you for posting.

You need to identify the exact task holding the semaphore causing the described behavior.

STM32CubeIDE offer many feature which could help you have a clear view on the execution of the tasks when using FreeRtos.

I advice you to check the UM2609 - Rev 7 chapter 6.2 and 6.3.

I will be waiting for your feedback as it is very important to improve the tool's features.

Kind regards,

Semer.

[leoneln]

Hi, thanks for replying

I did what you suggest and here is the capture:

 

 

There is a callback interruption that releases the semaphore:

void HAL_ETH_TxCpltCallback(ETH_HandleTypeDef *handlerEth)
{
 osSemaphoreRelease(TxPktSemaphore);
}

The interrupt never seems to happen and of course this blocks execution.

In addition, I reached to the function vListInsert() in list.c [FreeRTOS]. There is a "for" sentence and the exceution keeps there forever. Inside the function is a note:

/* *** NOTE ***********************************************************
		If you find your application is crashing here then likely causes are
		listed below. In addition see https://www.freertos.org/FAQHelp.html for
		more tips, and ensure configASSERT() is defined!
		https://www.freertos.org/a00110.html#configASSERT
 
			1) Stack overflow -
			 see https://www.freertos.org/Stacks-and-stack-overflow-checking.html
			2) Incorrect interrupt priority assignment, especially on Cortex-M
			 parts where numerically high priority values denote low actual
			 interrupt priorities, which can seem counter intuitive. See
			 https://www.freertos.org/RTOS-Cortex-M3-M4.html and the definition
			 of configMAX_SYSCALL_INTERRUPT_PRIORITY on
			 https://www.freertos.org/a00110.html
			3) Calling an API function from within a critical section or when
			 the scheduler is suspended, or calling an API function that does
			 not end in "FromISR" from an interrupt.
			4) Using a queue or semaphore before it has been initialised or
			 before the scheduler has been started (are interrupts firing
			 before vTaskStartScheduler() has been called?).
		**********************************************************************/

[leoneln]

[This answer need to be deleted]

[Piranha]

https://community.st.com/s/question/0D53W00001oImr4SAC/bug-stm32-lwip-ethernet-driver-tx-deadlock

https://community.st.com/s/question/0D50X0000BOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32