heinbali01 wrote on Tuesday, May 09, 2017:
I am in a scenario where I need to restart/reinit the Ethernet stack.
I have STM32Fxx driver and code, Is there any built-in function to do
the same ? I will be setting the new IP and related params before this
reset. MAC ID will be same, so I believe I don’t have to recreate the
IP task.
That is right, both the IP-task as well as the EMAC task ( prvEMACHandlerTask ) will keep on running.
The EMAC does not need a reset. If you want to change the MAC-address ( which you do not want to ), you can write the new MAC address into some registers.
You could do that every time when xNetworkInterfaceInitialise()
is called by calling prvMACAddressConfig()
.
HAL_ETH_Start/Stop is not helping much there.
Right, the EMAC settings haven’t change so the EMAC is not the problem.
I am able to get my required functionality done with just
FreeRTOS_SetIPAddress() and others params, but not reliable, few times
I get issue (for which I am thinking of reset now) as I have multiple
tasks and control is sliced to other tasks also. The issue is after I
try to set new IP, I see the timeout for ping requests (nothing from
stack will be responsive), I don’t see any assert/hang. Is there any
other way to read the device IP other than FreeRTOS_GetIPAddress()?.
Any input on phy/stack reset related will be helpful.
I think that you won’t be able to solve that problem on the embedded side. The problem is that you change a binding of a MAC-address with an IP-address. The host that you are working on is still using the old binding.
If my reasoning is true, the following should help within Windows: start a command prompt as an administrator. Enter the command arp /d *
to clean the local ARP tables.
For Linux: sudo ip -s -s neigh flush all
.
Beside that, you might see some time-outs, things might not work immediately.
Another issue that may occur is that the device does not connect through TCP after rebooting. That may be caused by the fact that your ipconfigRAND32()
function does not get a unique seed after booting.
When a TCP socket is bound to port 0, a random port number will be assigned. After a reboot, these port numbers should start at a different number.
Another thing that should be random is the Initial Sequence Number in a TCP connection. When the device uses the same port and the same initial sequence number, the connection is bound to fail.
Hein