TCP session terminated

[alejoseb]

    Hi alejoseb,

Thank you for the codes you posted. I used example ModbusF429TCP for my board. My board is STM32F429IGT6. My board with IP 192.168.1.190 is the client(master). I have used Modbus Slave software as a server(slave) in the system with IP 192.168.1.101. Currently,The problem is that after a short time of starting the connection, no more data is sent from the board side. At this moment, if ACK is not sent from the board side for the current slave packet, it will lead to retransmission from the slave side. The question is why the board as the master no longer sends data.. I am attaching the photos of Wireshark software and tools. Wireshark: Modbus Slave: STM32CubeIDE- main.c: STM32CubeIDE- freertos.c:

Originally posted by @Aimhighn in https://github.com/alejoseb/Modbus-STM32-HAL-FreeRTOS/issues/62#issuecomment-1333611574

[alejoseb]

Hi @Aimhighn I started a new issue since your question is not related to what was being discussed in the other thread.

I am not sure what could be the reason, most likely it is not related to the library.

You should check if the query returns correctly otherwise you can add some code to verify that as suggested in the loop of your last picture "//handle error".

In addition, you should check that the firmware is still running on your board, eventually your board crashed after performing several queries. Maybe your firmware is running out of RAM, check the heap configuration of your FreeRTOS.

[Aimhighn]

It doesn't reach the <//handle error> loop at all. After checking, it hangs in the queue as shown below and the queue does not return any value.

Since my Board and the example Board are F429 type. Therefore, the same memory setting has been performed. The heap memory configuration is exactly the same as the ModbusF429TCP example:

[alejoseb]

The RAM details in your summary image are not enough to determine if your FreeRTOS tasks are running out of RAM, since allocation is dynamic not static.

Please check if the stack of your task is similar to the example of the library:

https://github.com/alejoseb/Modbus-STM32-HAL-FreeRTOS/blob/742f6c8d3cc56bcbcf8245c626e2f4517ebf102b/Examples/ModbusF429TCP/Core/Src/freertos.c#L64

The error that you pointed is very likely to be related to lack of RAM. Also, I suspect the actual line of code where the execution hangs is not where you are pointing. You need to execute step-by-step even at assembly level. Usually it is inside the kernel.

[Aimhighn]

The RAM details in your summary image are not enough to determine if your FreeRTOS tasks are running out of RAM, since allocation is dynamic not static.

Please check if the stack of your task is similar to the example of the library:

https://github.com/alejoseb/Modbus-STM32-HAL-FreeRTOS/blob/742f6c8d3cc56bcbcf8245c626e2f4517ebf102b/Examples/ModbusF429TCP/Core/Src/freertos.c#L64

The error that you pointed is very likely to be related to lack of RAM. Also, I suspect the actual line of code where the execution hangs is not where you are pointing. You need to execute step-by-step even at assembly level. Usually it is inside the kernel.

I found the problem. In fact, According to the figure below, sometimes the condition here becomes true. queue.c file - Line 1433. (pxQueue->uxItemSize == 0) --> true: Then it falls into a infinite loop According to the figure below. FreeRTOSConfig.h file - Line 162: Debug and monitor via serial terminal: And the relative time of falling into this loop is also variable. Sometimes after a few minutes and sometimes after 15 minutes, it falls into this loop. I have tested this issue several times. And it always falls into this infinite loop. But I don't know why this happens and what is the solution?

[alejoseb]

That essentially is telling you that your FreeRTOS objects are being corrupted, because of lack of memory. Also, I don't know which printing function or Library you are using, but just calling that function can be consuming the whole stack memory of the tasks. Try incrementing the heap size and the stack size of the Modbus task. If you add printing statements to debug that will increase the memory usage even more. So either increase the memory or remove the printing statements at all.

[Aimhighn]

That essentially is telling you that your FreeRTOS objects are being corrupted, because of lack of memory. Also, I don't know which printing function or Library you are using, but just calling that function can be consuming the whole stack memory of the tasks. Try incrementing the heap size and the stack size of the Modbus task. If you add printing statements to debug that will increase the memory usage even more. So either increase the memory or remove the printing statements at all.

I checked completely. I removed all the commands I had entered with printing statements(printf and sprintf). I increased and decreased the heap size as well as the stacks size. The problem is from CMSIS V2. This version has bugs. I wish you had written this with CMSIS V1. According to some guys, CMSIS V2 has many bugs.

The link below explains the error I am having: https://community.st.com/s/question/0D50X0000BJ1iquSQB/bug-in-cubemx-ide-lwip-freertos-on-nucleo-f429zi

[alejoseb]

Thanks for diving deep in this issue. There are multiple issues reported on LWIP for STM32, I also documented one on the Readme file. We can keep this issue open till we determine which version of the HAL library is stable. I will do a couple of tests on my side as well. Besides, this issue is beyond the scope of the Modbus library, since it is not a bug in the library itself.

[Aimhighn]

Thanks for diving deep in this issue. There are multiple issues reported on LWIP for STM32, I also documented one on the Readme file. We can keep this issue open till we determine which version of the HAL library is stable. I will do a couple of tests on my side as well. Besides, this issue is beyond the scope of the Modbus library, since it is not a bug in the library itself.

Glad to help. This bug in this project was created in STM32CubeIDE V1.10.1 software based on the latest F4xx package. Yesterday, I installed the latest version provided by ST company, namely STM32CubeIDE V1.11.0 with the latest package. By installing this version, there are many bugs in CMSIS V2 mode apart from the example of your project. In this version, the operating system hangs in the < osKernelStart(); > line. So I recommend not to looking for any stable HAL library. As you and I know, there are three ways to implement RTOS instructions on the STM32 board: 1- CMSIS-RTOS API V1 2- CMSIS-RTOS API V2 3- FreeRTOS CMSIS-RTOS API Vx comes with changes every time the software is updated. Bugs are fixed and new bugs are appeared. (especially version 2 which is full of bugs).I am still not sure if these CMSIS V2 problems are related to compatibility or its own bugs because CMSIS V1 is supported by majority of STM32 devices But this majority support is not true for CMSIS V2.Therefore, the idea of using the instructions of these two method in the design of libraries is not suitable and interesting. I suggest you rewrite the Modbus library with FreeRTOS method. The instructions of this method are almost fixed and are less affected by the software API when the version is changed.

[alejoseb]

I already have a version that uses exclusively FreeRTOS methods, but it is not public since it is way behind the mainstream and only supports USART. Also, I am not sure what are the STM32 LWIP's dependencies on the CMSIS. Currently, this Modbus library depends on CubeMX and the HAL library to be portable to the majority of STM32 microcontrollers and to support USART, USB and TCP. Without CMSIS the library needs a preconfigured project with LWIP working flawlessly on FreeRTOS. There are some issues to consider before removing the CMSIS dependencies.

[Aimhighn]

Dependency on CubeMX and the HAL library is not a problem. Only you can rewrite it with CMSIS V1 if possible. By changing to version 1, your Modbus libraries need to be changed. If possible, change the libraries to be compatible with CMSIS V1.

best Regards.

[alejoseb]

I know that process and I purposely selected V2 since it is the newest version. I will not downgrade the library since V1 is not developed anymore. Also, V1 does not support ARMv8-M which is becoming popular on new MCUs, so definitely supporting V1 is not a priority. I can consider supporting both simultaneously, I will verify if that is possible.

[Aimhighn]

excellent. Have you used FreeMODBUS in your library? Creating two versions solves the problem, at least for Modbus TCP. We are waiting ....

[alejoseb]

This library does not use any component of FreeModbus.

[Aimhighn]

This library does not use any component of FreeModbus. Hello. I solved the problem by changing your library code from CMSIS V2 to CMSIS V1.

[alejoseb]

Ok, I will close this issue then.