TCP/IP connection problem after repowering

[direncan]

Hello,

I am currently using Olimex's STM32 E407 board. I am using raw tcp. I enabled lwIP on CubeMX. I have been able to create a TCP server, connect the board to my computer with ethernet cable and communicate. The problems I am facing now are as below:

1- I connected STLink V2 (an original one with 10 pins) to the board. Also, I am powering the board with this. Booting after first connection, it works as desired. When I replug the STLink, the board stops communication, and I cannot connect to the TCP server unless I boot the code from CubeIDE again or reset the board with button. Pinging the board gives "Destination host unreachable" error.

If I replug the ethernet cable without replugging STLink, it works ok. I am using user flash memory for booting and it is not volatile memory.

2- I disabled DHPC from CubeIDE -> lwIP and specified a static IP. I don't have a ethernet input in my PC so I'm using a hub. IP addresses are as shown below:

PC: 192.168.30.58
HUB: 192.168.30.89 (I specified from network settings of pc)

Board: 192.168.30.250 (specified from cubemx)

The problem is that: Even though I specified a static IP, when I type "arp -a" from terminal, I get board's IP as dynamic (IP is correct but not the type)

I don't know if these problems are related to each other but especially first problem is unacceptable. I won't be able to reach to the reset button. There won't be any connected STLink either.

I am also open to any solutions that may be done on connected PC. 

"NVIC_SystemReset()" -> this function is resetting the board from code but I need some kind of interrupt after repowering the board and use this function? 

[TDK]

A quick solution would be to implement a watchdog using IWDG that resets the chip after 10s, or whatever you deem sufficient, if a TCP connection is not established.

A better solution might be to connect a debugger to a chip in the stuck state, figure out what is going wrong and fix it. But that will certainly take longer. A watchdog in general is not a bad idea.

Other option might include doing a one-time reset at 10 seconds after reset if a TCP connection isn't established. You can use any of the timers to set this up, assuming you know where the code is at when it's stuck.