News:

Server migration complete, Welcome to version 2.1.1

+-+-

+-User

Welcome, Guest.
Please login or register.
 
 
 
Forgot your password?

+-Site Stats

Members
Total Members: 15526
Latest: stooge
New This Month: 34
New This Week: 22
New Today: 2
Stats
Total Posts: 127377
Total Topics: 15636
Most Online Today: 70
Most Online Ever: 7634
(January 21, 2020, 02:14:03 AM)
Users Online
Members: 2
Guests: 49
Total: 51

Beagle Board x36 networking issues.

Started by Hsteak2022, August 18, 2022, 10:50:09 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

fauxton

Ok I got BeagleBoneBlack boards of each of those revisions and set up scope probes to record how the reset looks on powerup.

The yellow trace is the 5v input supply (5V_VDD), green is "SYS_5V", blue is "DC_3.3V", and purple is the "SYS_RESETn" pin

The first shot is the Rev C board


The reset line rises over a messy period of about 40ms.

This second shot is a Rev C1 board (has C24 missing from the factory)


This newer revision board rises much faster, when I zoomed in I measured about 3ms

Now from everything I understand about reset circuits on microcontrollers, a reset signal is supposed to have a delay after power is applied and then rise extremely fast so that there is no bounce as the signal passes the threshold of each of the parts using it.  I'm rather surprised to see this awful RC rise time implementation.

On the BBB, C24 is a 2.2uF capacitor from the SYS_RESETn line to ground and C30 is 0.1uF capacitor from SYS_RESETn to ground.  These delay the reset line on it's way up to 3.3v.  I was amazed to not see a reset controller IC used on the schematic.

The link you provided from the beagleboard forum where they were experiencing the same issue as you seems to line up with what I am seeing.  When the reset signal is extremely slow, the PHY sometimes does not reset cleanly and is (inaccessible?) to the processor.  It would explain why they could always connect via USB tethering but had no ethernet sometimes.

I would recommend implementing a reset controller on the cape you're using.  The RC rise time the BBB is relying on is not considered safe practice from everything I know.  The problem was clearly noticed, as they removed the one capacitor from the newer rev c1 to speed up the reset rise.  I would assume you could safely modify rev c boards up to the c1 spec by removing capacitor C24 carefully.  The people in the link removed both capacitors and tried the ultimate test by writing a script to get some real test data of 1000 power cycles.  Before removing C24 and C30, they experienced 54/1000 failures.  After removing the capacitors, they had 100% success out of 1000 tries.

I'd be interested to see if there was any other documentation about this.  It seems like a serious flaw
I am building pixel interface capes for BBB - http://www.ledpixeldriver.com

Support FPP

+- Recent Topics

Can you start an effect and make it repeat with MQTT topic? by darylc
Today at 02:47:12 AM

Pi Hats Kits For Sale by Jorge Bolivar
December 07, 2022, 11:32:45 PM

f16v4 wont play in Player or Master Mode by aquinones3
December 07, 2022, 11:11:59 PM

Seamless Looping Virtual Santa Video(?) by nmiller0113
December 07, 2022, 10:39:58 PM

Composite Video by Bwinter
December 07, 2022, 08:59:31 PM

Expansion board and Diff Receiver CApacity by k6ccc
December 07, 2022, 08:17:57 PM

Pixel strands change color halfway through the string by jnealand
December 07, 2022, 06:58:16 PM

Remote script issue by jnealand
December 07, 2022, 06:40:46 PM

FPP 6.2 ColorLight Issues by dennismccreery
December 07, 2022, 05:13:50 PM

F16v3 found not responding by wilkija
December 07, 2022, 05:12:17 PM

Powered by EzPortal
Powered by SMFPacks Menu Editor Mod