not able to ping the STM32H750 device intermittently

[ckw089]

Hi,

Our project is using STM32H750 together with µC/OS-III as the OS and µC/TCP-IP as the network stack.

The device is able to be assigned with an IP address by DHCP server.

And the device can respond to ping initially.

But if we ping the device continuously, it will be kind of like disappearing from the network and no longer able to respond to the ping.

From IAR debugger, the Ethernet interrupt is still working. And we can still see the UDP packets are passed to µC/TCP-IP network stack.

But the network stack will no longer receive any ICMP (thus not responding to ping) or TCP packets.

What are things that could possibly go wrong here. Appreciate any suggestion on the areas that we should check.

rgds,

kc Wong

[MSG_ST]

Hi,

Thank you for sharing your problem.

• Could you please indicate if you are using STM32CubeFirmware driver ? if yes, which version ?
• After how long time the device disappear from the network ? (Seconds, Minutes, Hours..)
• Are you stressing the board or you are just pinging it continuously ?

Sorry for the delayed answer.

Regards

Mahdy

[ckw089]

Hi Mahdy,

• We are using the BSP provided by Micrium as part of their uC-TCP-IP stack.

GitHub - weston-embedded/uC-TCP-IP: A compact, reliable, high-performance TCP/IP protocol stack. Features dual IPv4 and IPv6 support, an SSL/TLS socket option, and support for Ethernet, Wi-Fi, and PHY controllers.

• not sure, didn't really track the duration when the device disappearing from the network
• just continuously ping the device at 1 second interval with below Python script

#!/usr/bin/env python
import os
import time
ip_list = ['10.82.101.75']
while True:
 for ip in ip_list:
 response = os.popen(f"ping {ip}").read()
 if"Received = 4" in response:
 print(f"UP {ip} Ping Successful")
 else:
 print(f"DOWN {ip} Ping Unsuccessful")
 time.sleep(1)

rgds,

kc Wong

[MSG_ST]

Hi,

I will list you some track and I hope that will help you :

• Make sure that Tx buffers are released after transmission

as defined here (HAL_ETH_TxFreeCallback)

• Make sur that the Mem Pool is big enough
• Make sure (if you are using cache management) that MPU is well configured
• Make sure that the SW is not stack on while(1) or something similar..

Regards

Mahdy

[ckw089]

Hi Mahdy,

Thanks for your suggestion. But I did not see any of them happens.

It is confirmed that when ping issue happens, the device is only able to receive the UDP broadcast packets and not UDP unicast packets by using the Python script TestUdpBroadcast.py and TestUdpUnicast.py.

TestUdpUnicast.py

import socket
 
UDP_IP = "10.82.97.142"
UDP_PORT = 5005
MESSAGE = b"Hello, World!"
 
print("UDP target IP: %s" % UDP_IP)
print("UDP target port: %s" % UDP_PORT)
print("message: %s" % MESSAGE)
 
sock = socket.socket(socket.AF_INET, # Internet
 socket.SOCK_DGRAM) # UDP
sock.sendto(MESSAGE, (UDP_IP, UDP_PORT))

TestUdpBroadcast.py

import socket
 
UDP_IP = "255.255.255.255"
UDP_PORT = 5005
MESSAGE = b"Hello, World!"
 
print("UDP target IP: %s" % UDP_IP)
print("UDP target port: %s" % UDP_PORT)
print("message: %s" % MESSAGE)
 
sock = socket.socket(socket.AF_INET, # Internet
 socket.SOCK_DGRAM) # UDP
 
# Enable broadcasting mode
sock.setsockopt(socket.SOL_SOCKET, socket.SO_BROADCAST, 1)
 
sock.sendto(MESSAGE, (UDP_IP, UDP_PORT))

Second proof is that Wireshark will not be able to capture the ICMP packets that indicates the destination unreachable (port unreachable) when ping issue happens.

In normal situation, the device will respond with this ICMP packets if it is able to receive the UDP unicast packets, but no process is listening at that UDP port.

The device also will not receive TCP and ICMP packets when ping issue happens as they are unicast also.

Anyway, the issue just disappeared mysteriously after I disconnect from and connect back the switch (where the device is connected to) to the company network.

The unanswered question is why unicast, and why not broadcast ?

So far, I have not been able to find anything in uC-TCP-IP stack or the Ethernet device on STM32H750 that links to this observation.

rgds,

kc Wong