Hi Apologies for dragging up a very old thread. I've been experiencing issues with Ethernet connections dying after prolonged operation in an electrically noisy environment, and I'm thinking maybe this is a grounding issue.
My application has isolation between the BBB and "outside" - it is powered using a 24V/5V isolated DC/DC converter to isolate from a potentially "dirty" 24 V supply which I do not control, all the digital I/O (also 24V) is fed through opto-isolators and converted to "clean" 3.3V. The unit is in a metal enclosure, and all parts of the enclosure, and all cable shields are connected to mains ground. Should I connect mains ground to BBB DGND (pin 1/2)? I'm concerned that it will reduce the effectiveness of my isolation efforts, since mains ground may be dealing with very large surges, and therefore may not be desirable to connect to the sensitive BBB? However, clearly leaving the DGND floating is not desirable either? Many thanks, Aaron On Thursday, 23 May 2013 14:18:01 UTC+1, Gerald wrote: > > I don't use the USB connection. I do use a grounded power supply which is > the way it must be done. If grounds are different, then you are asking for > trouble and creating such a scenario to create an issue does not really > prove anything. > > Gerald > > > On Thu, May 23, 2013 at 1:14 PM, Hussein Alasadi <[email protected] > <javascript:>> wrote: > >> Hey Gerald >> >> I have noticed that these issues are more prominent when the ground is >> floating, i.e. no USB connections to a PC and no metal ethernet connectors. >> Maybe you are testing with usb connected? I would leave a board with just >> power and ethernet with some ping flood running to try to reproduce it at >> your end. Hopefully we see (or don't see? hmm) something. >> >> Regards >> Hussein >> >> On Thursday, May 23, 2013 2:42:33 PM UTC+2, Gerald wrote: >>> >>> I understand you point. But why not after 5 min or 12 min? Why after an >>> hour? >>> >>> We have had these boards running for days. So I am more inclined to look >>> for a SW issue here. >>> >>> Have you looked at the schematic? >>> >>> Gerald >>> >>> On Thursday, May 23, 2013, Hussein Alasadi wrote: >>> >>>> Hey Gerald >>>> >>>> Actually I've seen it before that a glitch on the reset line somehow >>>> "locally" reset a chip, and the remaining chips on the same reset line do >>>> not get reset (capacitance of reset trace, minimum duration to hold reset >>>> can play a role). >>>> >>>> I've seen this on a custom audio cape I did, where touching a via >>>> connected to the reset trace next to the CODEC caused it to reset >>>> incompletely with corrupted registers, however the system did not reboot. >>>> This was ofcourse sporadic, sometimes touching the via did actually cause >>>> everything to reset. >>>> >>>> The problem is that I cannot probe this on the scope and wait for it to >>>> happen, since the ground terminal of the scope will earth the system and >>>> cause all the noise pickup issues to go away. A floating scope or >>>> differential probe would be needed but I don't have that at the moment. >>>> >>>> Suggestions? How could one reset the PHY during system operation? Is it >>>> possible through sysfs somehow? A SW workaround would require one to be >>>> able to do that. >>>> >>>> >>>> Regards >>>> Hussein >>>> >>>> On Thursday, May 23, 2013 1:21:27 PM UTC+2, Gerald wrote: >>>>> >>>>> Funny how the glitch only happens after an hour. Obviously there is no >>>>> damage or it would never come back. The reset line of the PHY is the >>>>> reset >>>>> line of the processor. I would expect to see a full board reset if this >>>>> were the issue. >>>>> >>>>> Gerald >>>>> >>>>> >>>>> On Thu, May 23, 2013 at 5:38 AM, Hussein Alasadi <[email protected] >>>>> > wrote: >>>>> >>>>>> Hey Everyone, >>>>>> >>>>>> I have been testing the beaglebone black for some time now, and I >>>>>> have noticed that the Ethernet tends to die after prolonged operation (1 >>>>>> day +). >>>>>> >>>>>> Beaglebone is run off of a good quality 5V DC supply, with constant >>>>>> traffic being streamed on it. CPU usage is around 40%. >>>>>> >>>>>> Below is the output of dmesg: >>>>>> >>>>>> [ 9.145976] net eth0: initializing cpsw version 1.12 (0) >>>>>> [ 9.150610] net eth0: phy found : id is : 0x7c0f1 >>>>>> [ 9.150644] libphy: PHY 4a101000.mdio:01 not found >>>>>> [ 9.155748] net eth0: phy 4a101000.mdio:01 not found on slave 1 >>>>>> [ 12.227778] libphy: 4a101000.mdio:00 - Link is Up - 100/Full >>>>>> *[102008.098372] libphy: 4a101000.mdio:00 - Link is Down* >>>>>> >>>>>> Link suddenly dies after many hours of being up. Beaglebone is >>>>>> connected to an ethernet switch and was left completely alone at that >>>>>> time >>>>>> (no tinkering). >>>>>> >>>>>> Upon attempting to revive the ethernet link without reboot, "ip link >>>>>> set eth0 down" seems to succeed, however "ip link set eth0 up" fails >>>>>> with: >>>>>> >>>>>> root@beaglebone:~# ip link set eth0 up >>>>>> [170649.910190] net eth0: phy 4a101000.mdio:00 not found on slave 0 >>>>>> [170649.916577] libphy: PHY 4a101000.mdio:01 not found >>>>>> [170649.921721] net eth0: phy 4a101000.mdio:01 not found on slave 1 >>>>>> >>>>>> *Observations*: after the ethernet dies, the orange light on the >>>>>> ethernet plug goes out, and the left LED blinks sporadically green. >>>>>> Unplugging the ethernet makes the left LED go solid green, right LED >>>>>> still off. >>>>>> Interestingly, the ethernet switch shows 1Gbps negotiation. Obviously >>>>>> link is not functional (but switch light is ON). >>>>>> >>>>>> Connecting the bone in this state to a 10/100 switch causes both LEDs >>>>>> on the bone to go completely off, while the 10/100 switch shows 10mbps >>>>>> negotiation. >>>>>> >>>>>> Rebooting the bone has no effect on ethernet (still dead): >>>>>> >>>>>> [ 5.705411] net eth0: initializing cpsw version 1.12 (0) >>>>>> [ 5.707104] libphy: PHY 4a101000.mdio:00 not found >>>>>> [ 5.712133] net eth0: phy 4a101000.mdio:00 not found on slave 0 >>>>>> [ 5.718328] libphy: PHY 4a101000.mdio:01 not found >>>>>> [ 5.723339] net eth0: phy 4a101000.mdio:01 not found on slave 1 >>>>>> >>>>>> Only a power cycle or pressing RESET on the board fixes this: >>>>>> >>>>>> [ 8.242920] net eth0: initializing cpsw version 1.12 (0) >>>>>> [ 8.256913] net eth0: phy found : id is : 0x7c0f1 >>>>>> [ 8.256950] libphy: PHY 4a101000.mdio:01 not found >>>>>> [ 8.262017] net eth0: phy 4a101000.mdio:01 not found on slave 1 >>>>>> >>>>>> *[ 11.333235] libphy: 4a101000.mdio:00 - Link is Up - 100/Full * >>>>>> >>>>>> Could this be the RESET line of the PHY picking up some glitch? I >>>>>> havn't checked the schematics/layout but I hope it turns out to be a cap >>>>>> being needed on the PHY reset line. Otherwise, I can't thing of >>>>>> something >>>>>> else. >>>>>> >>>>>> Gerald: Help? >>>>>> >>>>>> Regards >>>>>> Hussein >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> For more options, visit http://beagleboard.org/discuss >>>>>> --- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "BeagleBoard" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Gerald >>>>> >>>>> [email protected] >>>>> [email protected] >>>>> http://beagleboard.org/ >>>>> http://circuitco.com/support/ >>>>> >>>> -- >>>> For more options, visit http://beagleboard.org/discuss >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "BeagleBoard" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> For more options, visit https://groups.google.com/groups/opt_out. >>>> >>>> >>>> >>> >>> >>> -- >>> Gerald >>> >>> [email protected] >>> [email protected] >>> http://beagleboard.org/ >>> http://circuitco.com/support/ >>> >>> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > > > -- > Gerald > > [email protected] <javascript:> > [email protected] <javascript:> > http://beagleboard.org/ > http://circuitco.com/support/ > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/a8e80d83-2726-41b9-a6f1-0ef83fdcc6ca%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
