2022-12-15 11:06 AM
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.
2022-12-15 11:12 PM
Hi,
What version of FreeRTOS you are using V1 or V2 ?
2022-12-16 02:21 AM
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.
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
2022-12-16 07:24 AM
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
2022-12-16 07:57 AM
[This answer need to be deleted]
2022-12-16 07:57 AM
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?).
**********************************************************************/
2023-01-07 06:19 PM