NETMF / netmf-interpreter

.NET Micro Framework Interpreter
http://netmf.github.io/netmf-interpreter/
Other
487 stars 224 forks source link

Network Stack broken by unplugging ethernet cable? #360

Open maiorfi opened 8 years ago

maiorfi commented 8 years ago

Hi.

I recently spotted that unplugging ethernet cable from Keil dev board (once .NETMF has regularly booted) "breaks" tcp/ip stack in some way, since it doesn't reply to ping anymore once cable is reconnected.

Any idea?

Thanks!

smaillet-ms commented 8 years ago

Can you check the debug output? It should show information about DNS requests etc... Can you see activity with a network analyzer( like Wireshark, EtherReal, etc...). This is a scenario we tested and verified quite often while building the 4.4 release.

smaillet-ms commented 8 years ago

Another thought is that you unplug it and plug back in so fast that the system never saw it go away. Unfortunately, the design of the MCBSTM32F400 hardware doesn't provide an interrupt for the cable removal so the code has to resort to periodically polling. If you unplug the cable and plug it back in again between polling points then the code never thinks it was removed. (A lesson for hardware designers out there - always make that a hardware interrupt!!)

maiorfi commented 8 years ago

Do you mean debug output coming from swo channel? Il 14 dic 2015 18:57, "Steve Maillet" notifications@github.com ha scritto:

Can you check the debug output? It should show information about DNS requests etc... Can you see activity with a network analyzer( like Wireshark, EtherReal, etc...). This is a scenario we tested and verified quite often while building the 4.4 release.

— Reply to this email directly or view it on GitHub https://github.com/NETMF/netmf-interpreter/issues/360#issuecomment-164510422 .

maiorfi commented 8 years ago

How long is polling interval currently? I think I waited something like 4-5 seconds before plugging cable back. Il 14 dic 2015 19:00, "Steve Maillet" notifications@github.com ha scritto:

Another thought is that you unplug it and plug back in so fast that the system never saw it go away. Unfortunately, the design of the MCBSTM32F400 hardware doesn't provide an interrupt for the cable removal so the code has to resort to periodically polling. If you unplug the cable and plug it back in again between polling points then the code never thinks it was removed. (A lesson for hardware designers out there - always make that a hardware interrupt!!)

— Reply to this email directly or view it on GitHub https://github.com/NETMF/netmf-interpreter/issues/360#issuecomment-164511328 .

SytechDesigns commented 8 years ago

At least you got your Ethernet working long enough to break it!!! I am having immense difficulties getting Ethernet working on the MCBSTM32f400 ( ver 1.2) - but I can tell you that the polling interval is one second when the network is up and 15 seconds if it is down - look in STM32F4_ETH_lwip_adapter.cpp - lwip_network_uptime_completion - at the end of the function if linkstatus is true, then queues next completion for 1 second, if linkstatus is false then queues the next completion in 15 seconds. Are you building from the source zip downloaded from the root page of here ( the release stuff) or are you building from a clone of the repository? I am using the release zip - The network up is detected, if I unplug the cable it detects its down and replug in, it detects it back up. I get dma receive interrupts, and received data is then posted in the rtos message queue for lwip handling - but that's as far as I have debugged, I get no DHCP request sent, so do not get a dhcp address, and if I set up a static ip address, I get no response to pings etc..... I know the board and infrastructure are working, I have written a simple lwip app for the board and that works with dhcp and I can ping it etc. - just not getting rtos handling and clr talking to each other! Don't suppose you could send me your hex image files, so I can at least see that its possible to work?

maiorfi commented 8 years ago

Hi.

I just uploaded binaries built in debug flavor at following address: https://dl.dropboxusercontent.com/u/7414592/NETMF44_MCBSTM32F400_Debug_Binaries.7z

Thanks!