element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Raspberry Pi
  • Products
  • More
Raspberry Pi
Raspberry Pi Forum RG1 1.8v regulator
  • Blog
  • Forum
  • Documents
  • Quiz
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Raspberry Pi to participate - click to join for free!
Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 231 replies
  • Subscribers 669 subscribers
  • Views 26241 views
  • Users 0 members are here
Related

RG1 1.8v regulator

Former Member
Former Member over 13 years ago

Ok, so in a different thread I threatened to remove RG1 and do some current measurements on it's output after seeing those thermal images that show it's not generating any heat...

 

Well, I did it tonight. Some photos here: https://picasaweb.google.com/selsinork/RPi18v

 

The jumper pins in the output let me either just put a jumper on and verify the Pi boots ok, or wire a multimeter in series to get some current readings.

 

The results were interesting to say the least. I had to go back and check I was reading the multimeter correctly, that it wasn't broken etc.

 

On initial power up I see a negative current for a second or so which then reverses to about 0.5mA (yes half a milliamp, that's not a typo) for a few seconds while we get the first sd-card accesses. Once we're booted and sitting at the login prompt the current reading fluctuates from around 0.001mA to maybe 0.04mA. 

 

I'm using the 40mA range on a decent Fluke multimeter, so I've no reason to doubt the results. There's obviously going to be some inaccuracy down at that level due to length of meter leads etc, but the result is fairly clear.  You'll understand why I was checking the meter was working and I was reading it correctly though image

 

 

So from there onto the next test, lets try completely disconnecting RG1 and see if the Pi boots while using the LAN9512 1.8v 'output'.  Yes it does! 

 

I think that's reasonably good indication that jamodio got it spot on, the lan9512 shouldn't be connected to the 1.8v plane and it's heat problems are going to be largely due to supplying current on it's 1.8v filter pin that it was never designed to do.

 

So anyone willing to pull RG1 off a Pi and verify my results ?

  • Sign in to reply
  • Cancel
Parents
  • electron2
    electron2 over 13 years ago

    As shown in Troy Mackay's post on Jul 28 it seems to me that we could mod our PI's to work more as the chips were designed.

     

    I think that this could make the PI more stable, from the looks of it.

     

    I am not a designer Just an old tech, but I think we need to find a way to FIX what we now know is an error in the board.

     

    So could someone do some practical testing to see if there is something that can be done to easly fix the current board, rather than wait for RPI foundation to fix it by waiting for a board redesign?

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to electron2

    i will love to try out the hack Troy mackay has done also and then test again with that fix on the board, but i have looked into this and i most say it is very well done by Troy as i think it is to small for me todo and i done have an microscope as need for this.

     

    so yes if some one can findout where to make an cut to split the LAN9512 1v8 from the lod 1v8 then i will try this also.

     

     

    Tooms

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to morgaine

    certainly there have been plenty of opportunities on the

    RPi forum and twitter for someone to say yes we have a

    design error and it is causing chip temperatures to get hotter

    than they are supposed to.

     

    On the recent "case with fan" thread:

    http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=14323

    bredman replies:

     

    "1. The chips in the RPi are supposed to run hot, they are designed to operate safely to 120 degrees C."

     

    On twitter, a similar question about fans is asked:

    https://twitter.com/scottfrye/status/234232917583343616

     

    Liz's reponse is:

    "we're making good progress on the heat issue that some of

    you are experiencing, with expert help from the other forum."

    Oh wait, that's not quite what she said.  Instead she said:

    "Why do you need a fan?"

     

    Ron K Jeffries further clarifies: "It runs very cool, even when

    overclocked to 900MHz.  Unless you live in the Mojave desert,

    you'll not need a fan."

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • morgaine
    morgaine over 13 years ago in reply to Former Member

    I think you said it best some months ago, that facts and honesty "interfere with her right to a new kitchen". imageimageimage

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • johnbeetem
    johnbeetem over 13 years ago in reply to Former Member

    coder27 wrote:

     

    There's a report today of a guy who thinks there is a correlation

    between hot chips and ethernet cutting out and keyboard repeats.

     

    http://www.raspberrypi.org/phpBB3/viewtopic.php?f=24&t=14478

     

    "Mine gets pretty hot. Heat I don't mind, but when it does get hot,

    the ethernet cuts out and the keyboard repeats happen more often."

    Here's my latest hypothesis.  We're seeing three outcomes of the regulatory battle between RG1 (1.8V regulator) and IC3 (LAN9512).

     

    1.  RG1 has substantially higher Vreg than IC3 and thus provides essentially all the current for 1V8.  IC3's regulator switches off and IC3 runs nice and cool.

     

    2.  IC3 has substantially higher Vreg than RG1 and thus provides essentially all the current for 1V8.  IC3 get very hot, but still functions OK, at least for now.

     

    3.  RG1 and IC3 have almost identical Vreg and the regulation is unstable, with the current alternately being sourced by RG1, IC3, or both, depending on RG1 and IC3 temperatures.

     

    (3) is probably quite uncommon since it requires almost idential Vregs, but if it does occur might add enough ripple to 1V8 to cause USB and Ethernet failures.  It would be interesting to put a 'scope on 1V8 near IC3 to see what it looks like on boards with USB/Ethernet problems not otherwise explained.  It shouldn't affect IC3's PLL since the PLL has its own regulator and its own 1.8V filtering, but if IC3 is rapidly warming and cooling you might get some PLL instability.

     

    It's also possible that (2) is causing local heating inside IC3 that's slowing a critical path enough to cause USB/Enet failure.  If path delay is right at the edge, process variation or case design could make the difference.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • morgaine
    morgaine over 13 years ago in reply to johnbeetem

    Good summary.  It's worth pointing out also that voltage is only one electrical parameter here.  If any instability is present, the added inductance from the incorrect connection could also be relevant given that the LAN9512 expects nothing but decoupling caps on these tracks.

     

    The 1V8 LDO powers PLL circuitry in the LAN9512, so stability is important.  Those 3 caps won't be decoupling the LAN9512 as effectively if they're simultaneously part of a larger on-board 1.8V mesh, even if that mesh is not misbehaving electronically.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • johnbeetem
    johnbeetem over 13 years ago in reply to morgaine

    Morgaine Dinova wrote:

     

    Good summary.  It's worth pointing out also that voltage is only one electrical parameter here.  If any instability is present, the added inductance from the incorrect connection could also be relevant given that the LAN9512 expects nothing but decoupling caps on these tracks.  The 1V8 LDO powers PLL circuitry in the LAN9512, so stability is important.

    According to the LAN9512 data sheet (Figure 2.2 -- Power Connections), the PLL has its own +3.3V to +1.8V regulator.  It appears to be wired up correctly in the RasPi schematics.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • morgaine
    morgaine over 13 years ago in reply to johnbeetem

    I wasn't so sure about their complete independence inside the LAN9512 when looking at the datasheet.

     

    The VDD18ETHPLL and VDD18USBPLL lines are also connected to L3 which is specc'd at 100MHz so it seems strongly related to dynamic PLL operation (L3 is isolating ETH and USB sections from each other for RF, similar to L4 on the 3V3 side), and neither of those PLL lines has a tank cap like the 4.7uF on the 1V8CORE lines, so it doesn't seem to be caring about low-frequency stability.  That suggested to me that the PLL's 1.8V may actually be affected by the core 1V8 LDO, if not directly as a source (which seems unlikely since it's fed from 3V3) then at least indirectly through core logic.

     

    When SMSC go to all the trouble of inductively isolating the USB and ETH sections of both their 3V3 and 1V8 LDOs, it's easy to imagine that they're not too impressed when their 1V8CORE pins are coupled to something foreign.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • jamodio
    jamodio over 13 years ago in reply to morgaine

    There are also some additional bits of information to consider based on reports of problems with Ethernet and the X1 crystal. If there are indeed power issues on the SMSC core that may produce unstable operation of the internal clock signals and ethernet is particularly picky about clock jitter and shape which may get the part to operate out of the IEEE specs. I've seen this problem with some Ethernet controllers/PHYs where temperature produces too much drift on the crystal/oscillator and the ethernet link is lost.

     

    And who said that the parts on the R-pi are rated to operate at 120C ?

     

    The PoP RAM chip on top of the SoC is rated for Commercial temp ranges, it varies from mobile to normal applications but it does not exceed 95C.

     

    There is a lot of clueless folks at the R-Pi forum contributing wrong information to the already existing confusion.

     

    -J

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • Former Member
    Former Member over 13 years ago in reply to jamodio

    There's a dedicated thread now in the other forum.

     

    http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=14489

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • jamodio
    jamodio over 13 years ago in reply to Former Member

    Love the classical cryptyc response from RPF minions ...

     

    -J

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
  • morgaine
    morgaine over 13 years ago in reply to Former Member

    coder27 wrote:

     

    There's a dedicated thread now in the other forum.

     

    http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=14489

     

    From that thread:

     

    JamesH wrote, on the RPF forum:

     

    Cannot say much about this, except that the Foundation are aware

    of the problem and are working to rectify it.

     

    And why exactly can the Foundation not say much about it?

     

    This is a board intended for technical education, not a secret product hiding trade secrets for commercial advantage.  Why are essential items of information like the gerbers hidden?  Why are problems hidden?  Why are solutions hidden?  Why are future plans hidden?

     

    I think I can summarize the questions more succinctly, if less politely:

     

    Why is the Foundation full of it?

     

    Morgaine.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
Reply
  • morgaine
    morgaine over 13 years ago in reply to Former Member

    coder27 wrote:

     

    There's a dedicated thread now in the other forum.

     

    http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=14489

     

    From that thread:

     

    JamesH wrote, on the RPF forum:

     

    Cannot say much about this, except that the Foundation are aware

    of the problem and are working to rectify it.

     

    And why exactly can the Foundation not say much about it?

     

    This is a board intended for technical education, not a secret product hiding trade secrets for commercial advantage.  Why are essential items of information like the gerbers hidden?  Why are problems hidden?  Why are solutions hidden?  Why are future plans hidden?

     

    I think I can summarize the questions more succinctly, if less politely:

     

    Why is the Foundation full of it?

     

    Morgaine.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
Children
No Data
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube