VF50 Ethernet port hangs with UDP frames


I’m using a VF50 module with Wince6 Toradex image, connected to a local ethernet network. (use of ‘ENET2 link’). It receives UDP frames each 2s. After ca 8h, the ethernet port seems blocked, impossible to ping the module. Connection via USB/Windows Mobile Device center OK, processes running normally, the DialUp & Network connections icon “ENET2” doesn’t respond anymore. From CerHost, impossible to ping, ipconfig starts a new line but hangs. The ethernet network of wince 6 seems then KO. Hardware Reboot is necessary to restart the ethernet port.
It’s a very annoying problem for us as it’s a simple use case of UDP transmission. Without those UDP frames, the port doesn’t have problems, for instance with TCP frames.
Any ideas please ?


Could you please share a BSP version of Wince6 you are using?

It’s BSP version 1.7 (date = 01/05/2020) of wince6…

Have you tried the latest (V1.8) release of WINCE?

No, but it’s a problem to migrate to 1.8 BSP because it requires a major intervention on our client’s system. And 1.8 BSP doesn’t seem to fix any ETHERNET bugs unless you have additional info on it (a possible ethernet driver problem?)

WinCE 6 was not updated from 2018. I’d recommend to try to run your app on WinCE 7. In most cases such transition will not require any source code re-compilation or modification.

Migration to WINCE7 needs to rebuild the register database and some time too correct problems. We’ll try it but, without information, it’s hard to know if it’s worth spending time on this port…

In WINCE6, do you know if it’s possible (and how) to detect such network loss to trigger a reset ?

I/m not suggesting to do a migration for your whole project. You can just create simple app which will demonstrate this issue under WInCE 6 and then try to run it under CE7 .

Unfortunately it’s not possible to reset Ethernet chip only without resetting the whole module. However you can do a whole system reset programmatically by connecting nRESET_EXT (X1pin 26) to some GPIO and toggling that GPIO when needed.