VF50 not correctly restarting when connected to an ethernet link

We are using VF50 modules with Wince6 image 1.6b4, connected to a local ethernet network. (schematic conform to the Colibri Carrier Board Design Guide v1.5; use of ‘ENET2 link’)
Sometimes, one module doesn’t restart correctly after a hardware or software reset : in that case, no ping is possible, no connection via USB/Windows Mobile Device center is possible.
When the problem has appeared and we disconnect the ethernet link, the VF50 always restarts after a hardware reset : connection via USB/Windows Mobile Device center OK, processes running, … But no way to establish an ethernet connection if we plug an ethernet cable (no ping).
In that case, the only way to make the board working correctly is to switch off, wait 5s min, then switch on.
When the problem is present and an ethernet cable plugged, the ethernet leds constantly blinks, even if no other device is present on the network…
The problem arrives randomly, we havn’t found a way to make it repetitive.
Any ideas ?
Thanks for your help .

Can this be a back feeding issue? I mean some voltage is driven to Vybrid module from ethernet cable when it should not.

This is quite common on Vybrid and difficult to debug.

I had the same issue with VF61 and USB cable plugged.

You can try holding the reset asserted and measure the voltage level of the main imput rail (3.3V_COLIBRI).

I had 800-900 mV from USB and this gave sporadic boot issues.

If this is the case you should find a way to reduce it (maybe a higher resistor somewhere).

Thanks for your suggestion Vix. We have made some measurements : The main input rail voltage is not affected by the ethernet cable …

Dear @vf50user

To understand the issue better, and hopefully track down the root cause, please execute the tests as described below, and post the results:

  1. What exactly are you referring to by ‘ENET2 link’? Is this the default Ethernet port, or did you add a second Ethernet interface?
  2. Do you see the same issues if the module is running in one of our standard carrier boards (e.g. Colibri Evaluation Board, Iris)?
  3. Please Enable the debug messages. Please send me the log output of a working boot and a non-working boot.
  4. How far does the module boot in the non-working case?
    I hope we see the answer to this question in the boot log output of the previous question.
  5. In the non-working case, is there any sign that the OS is running, for example can a mouse cursor be moved?
  6. Did you try to connect the Colibri to a different Ethernet hub/switch?
  7. How often does the problem appear approximately (1% of the boot cycles, 50% of the boot cycles?)
  8. Is there any other condition I need to meet, in order to be able to reproduce the issue on my desk?


Dear @vf50user
vix was referring to the USB cable, which might be connected as you mentioned that the USB/WMDC connection shows no reaction).
Ethernet is not an issue for backfeeding, but another common source of backfeeding are the UART ports.
Regards, Andy

Dear Andy,

1 : yes, we only use the default ethernet port.

2, 3 : Unfortunately, it’s not possible to run our application on one of your standard carrier board, because our VF50 board must run with a second processor based on our specific carrier board.
This specific carrier board doesn’t output any UART, so we can’t see any boot log output …

4 - 5 : When not working, the VF50 doesn’t boot after a reset if the ethernet cable is plugged. If no ethernet cable is plugged, the VF50 seems to run correctly (use of Cerhost on the USB OK, exchanges correct with our 2nd processor based on the specific carrier board, …) except the ethernet link (no communication possible, no ping)

6 : Yes, we try to connect the Colibri to different ethernet router/switch (MOXA, Dlink, TPlink). It seems to be independent from the router/switch.

7 : Difficult to say, because not often (hopely, but too enough for a 24h/24h installation which can be reseted. perhaps 1% ???)

8 : When we see the problem, the ethernet link was constantly charged with UDP frames transmitted by other controllers (around 6 UDP frames/second). But, after that, disconnecting the other controllers from the network doesn’t help the faulty controller to restart correctly after a hardware reset.
In that case only switching off (min 5s) / switching on make the controller restart as it should do.

Thanks for your help.