I’m working on a STM32F769I-Eval demoboard. I have a FreeRTOS and FreeRTOS-Plus-TCP running on it. I can ping the board with a 100% success.
The TCP-IP lib version is version 2.3.2. With the version of the LTS archive, there is no response at all to the ping, with the same application code.
When I start a basic TouchGFX 4.21 Application, even without any refresh, the Ping response fall to 30%.
i know this is probably a TouchGFX more than a TCP problem. But does any one has an idee how to solve this?
The priority of the TCP-IP task is the default one, so configMAX_PRIORITIES - 2. (The task is started in another task, does it change anything?)
The TouchGFX priority is lower (osPriorityVelowNormal) and the FreeRTOS is configured with configUSE_PREEMPTION 1
I have defined configUSE_MALLOC_FAILED_HOOK 1, and a
void vApplicationMallocFailedHook(void) { configASSERT(0); }
as suggested in another thread on the forum
There are not assert!
If some one knows TouchGFX, as the application has no animation, the refresh rate is not so important. How can I reduce it to avoid the TCP task miss some ping packet? Or is there any other possibility to reduce MCU consumption by TouchGFX?
I will reach out to our FreeRTOS-Plus-TCP team and see if they may be able to help you, but I should mention that they are probably not very familiar with TouchGFX ( neither am I, sorry ), so would recommend reaching out to the maintainers of that library if you haven’t already. The fact that it’s dropping to 30% would indicate that IP-Task may be getting starved and can’t respond to the ping in time. See FreeRTOS Run Time Stats to learn how you can output runtime statistics for your application - this may help identify resource consumption. I’m not terribly familiar with TouchGFX but if the IP task is at a higher priority - it should be starving GFX, not the other way around. Is it possible that TouchGFX starts a task underneath that is at a higher priority? It may also be possible that this is a case of priority inversion, in which TouchGFX has control of a resource that the IP-Task blocks on (Priority inversion - Wikipedia), but I’m just throwing that out there as a possibility. Please post the run-time statistics if you can :).
Blockquote With the version of the LTS archive, there is no response at all to the ping, with the same application code.
When you mention the LTS archive, do you mean version 3.1.1? It should still work from my understanding … so this may be an issue with the newer library version, so thank you for bringing this up. It would be helpful if you could give your config files for FreeRTOS+TCP :).
Blockquote The task is started in another task, does it change anything?
The task being started from another task won’t have any effect on its priority - FreeRTOS does not have “child” tasks, etc.
Hello,
Thank you for your reply. I will have a look to check the run-time statistics.
The problem with the LTS version 3.1.0 (there is a 3.1.1 version? ) was that I do not report 2 modifications in the lib NetworkInterface.c:
In the file, there is a definition of
static ETH_HandleTypeDef xETH;
I change it to (and all the reference to it)
extern ETH_HandleTypeDef heth;
This variable is define in the eth.c file of the Core directory in the STM32Cube generated projet. There is something not working when using the FreeRTOS-Plus-TCP lib without using the initialisation of the HAL_ETH_Init.
So the TouchGFX task is not consuming so much MPU. Those really useful statistics, are not so helpful for my problem! With 95% of idle time, the IP task should be capable to answer all the ping no?
Just one question. Do you know why sometime there is a instead of the complete statistics?
Yes, I’m talking about ICMP pings. With Wireshark I can see the ping requests, and some get a reply, and some other not. When there is a reply, it is within 1ms (more 0.2ms)
I was talking about the “<NUL>” (sorry, is was not displayed in my question). The problem was in the UDPLogging task is was using. The buffer was too short for a correct display
Still investigating. I have simplified the TouchGFX task. Less than 3%, still got not response.
When there is no response, the ProcessICMPPacket() function is not called.
Both functions seems to be called. Just I’m not sure it is because of ping. The ping is send form a Windows PC, and there are other packet being send
Edit:
I have build a network with just to board, so no other frame than ICMP Ping. And Yes, the functions are called, even when there is no outgoing ping
configASSERT( x ) if ( ( x ) == 0 ) { taskDISABLE_INTERRUPTS(); for(;;); }
This functions are called when a packet is received by the device. The next step is to follow the path - prvHandleEthernetPacket --> prvProcessEthernetPacket --> prvProcessIPPacket --> ProcessICMPPacket and try to see why ProcessICMPPacket is not getting called.
Sometime, prvProcessEthernetPacket is called, but when checking pxEthernetHeader->usFrameType it is seen as an ipARP_FRAME_TYPE and not a ipIPv4_FRAME_TYPE.
In other case, ProcessICMPPacket is called and return with eReturnEthernetFrame.
Finaly, xNetworkInterfaceOutput is called and return pdPASS but no response is seen from the Ping sender.
Thank you for doing those investigations - great work! I assume both the findings are for dropped PING responses.
This is okay as it means that the received packet is ARP packet.
This is problematic - We need to trace down what is happening here. Are we not even handing the packet to NIC or are we handing the packet to NIC and it is not putting it on wire?
Sorry i am not pro to TCP-IP but why do the board receive ARP packet while Ping is ICMP?
I had another case where, in the prvProcessIPPacket, is stop after check APR resolution because the response of xCheckRequiredARPResolution was not true and so eRetrun = eWaitingARPResolution
Still investigating on the problem. I just reproduce it. Seems the xNetworkInterfaceOutput execute to the end and the xReturn = pdPASS I will have to go down in the code!
Ok, but why does the board receive only ARP packet while it should receive ICMP packet.
One of the case I have seen today, is:
Packet is received and prvProcessIPPacket is called
There is a xCheckRequiresARPResolution that return pdTrue. After that the ProcessICMPPacket is not called. at the end, FreeRTOS_OutputARPRequest is called.
I have seen it on the first ping. So maybe it is a normal behavior? Seems strange to me!