RG1 1.8v regulator

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?

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

selsinork wrote:

 

If you're a software person, you're probably familiar with unit testing.  IME it suffers from variants of the same problems.

1. The spec is wrong, unit test to the letter of the spec and the result is wrong, but the test passes.
2. Often the person who writes the code also writes the unit test for it, if they have some misunderstanding of the requirement, the test will pass but the result is still wrong.

Expanding on (2), IMO you should always have different people designing and testing.  A good designer wants to make something work, a good tester wants to break it.  Getting both mind-sets in one person is a rarity, and inevitably leads to a conflict of interest.  Also, humans have difficulty perceiving what's really there versus what they want to see -- you should have someone else proofread your writing, and review your designs.

selsinork wrote:

 

Agree, but as the complexity grows you're increasingly faced with a datasheet being 1000 pages instead of 50. It's trying to reduce ambiguity, but it's bringing up the needle in a haystack problem.

There are good and bad tech reference manuals out there.  It all depends on whether the vendor sees a manual as (1) a way to get more design wins and require less tech support, or (2) an painful burden to be dispatched as cheaply as possible.  A 1000-page TRM isn't a problem if it's well-organized -- I can just print the chapters I need for my particular application.  Many SoCs have all sorts of functions that I don't need, so I can just ignore them provided that the SoC is well designed and there aren't unexpected interactions.  OTOH, some 3000-page TRMs are that way because the writer copied and pasted identical functions and then made small changes to each copy instead of thinking out clearly what would be most helpful to the designer and making one copy with a table of individual differences.

When a manufacturer is dodgy about documentation, it makes me wonder how well their products are designed, since a well-designed product generally starts with a well-written specification, which then provides the basis for a well-written TRM which doesn't cost much to complete.

John Beetem wrote:

 

When a manufacturer is dodgy about documentation, it makes me wonder how well their products are designed, since a well-designed product generally starts with a well-written specification, which then provides the basis for a well-written TRM which doesn't cost much to complete.

A TRM is written as much for the manufacturer's own staff as for the external audience.  If a company can't be bothered to describe to its own staff how its product works, it doesn't inspire any confidence that its staff actually knows how it works, so you can expect support and the company's support products to be poor or non-existent.

Orthogonal to the above, the days of monolithic TRMs or other large specification documents should have disappeared long ago.  Scalability refers not only to systems but to documentation as well.  Any non-trivial document needs to be hierarchical, distributed, and revisioned at each level of hierarchy, or it has no hope of being maintained to track the thing it describes.  Unfortunately today's prefered format for technical specs favours monolithic documentation.

Even if the delivery is "monolithic", internally inside the company the separation should take place.

With "monolithic delivery" I mean: "A single datasheet that describes the whole chip".

With separation I mean that the different chapters are maintained and written separately.

Care must be applied to ensure that when a module is functionally upgraded, the datasheets for the previous versions of that module don't get more complicated.

Having now read the last few pages of this thread....

The LAN chip is not designed to deliver power on the 1.8V. To stick to the specs the two signals need to be decoupled. i.e. a PCB redesign.

In practise the draw on the 1.8V is about 100mA. This means 3.3V-1.8V * 100mA = 150mW of power moves from the LAN chip to the regulator.

In practise, on the total power-draw of almost a Watt, the lan chip will be able to handle the 1/6th of a watt extra power. Maybe not over the full temperature range, so stuffing the 'pi into a mostly-closed enclosure may lead to unneccessary problems.

No recall of existing 'pi boards needs to be done. As said: The lan chip can handle it in practise, it is a question of conforming to the specifications, and being more robust.

If you are comfortable with using chips outside the official specifications, you can save a bit of cost if you leave off RG1. As it seems to work with RG1 removed, or with RG1 there is little current flowing from it. The lan chip seems to be able to cope.

Some people are expressing views that paralleled regulators will have one delivering ALL the current, and the other one none. This is not always the case, This would be the case if they are both ideal voltage sources (with an ideal diode in series). However in practise, both regulators would have a measureable output impedance. So if regulator 1 delivers 1.85V with an impedance of 1 ohm, and the other delivers 1.80V with an impedance of 0.1ohm, the first 50mA will be mostly delivered by the first regulator, but increasing the current draw to 100mA, the second regulator will provide about 50mA of that.

Roger Wolff wrote:

 

Some people are expressing views that paralleled regulators will have one delivering ALL the current, and the other one none. This is not always the case, This would be the case if they are both ideal voltage sources (with an ideal diode in series). However in practise, both regulators would have a measureable output impedance. So if regulator 1 delivers 1.85V with an impedance of 1 ohm, and the other delivers 1.80V with an impedance of 0.1ohm, the first 50mA will be mostly delivered by the first regulator, but increasing the current draw to 100mA, the second regulator will provide about 50mA of that.

The thing is, that isn't how regulators work, they aren't a voltage source with a resistive output.

Regulators, including the two linear regulators we're dealing with here pretty much always consist of a voltage reference with a feedback circuit controlling a variable resistance between the input power pin and the output power pin provided by either a FET or a bipolar transistor. If the voltage on the output pin is above the reference voltage by more than a tiny amount then the feedback circuit will shut off the output transistor and nearly all the power will be provided by the device with the higher reference voltage. Where it gets funny is when the two reference voltages are very close, both regulators provide part of the power and you can get into oscillations and all sorts of fun and games depending on the impedances around the circuit.

A TRM is written as much for the manufacturer's own staff as for the external audience.  If a company can't be bothered to describe to its own staff how its product works, it doesn't inspire any confidence that its staff actually knows how it works, so you can expect support and the company's support products to be poor or non-existent.

You've not worked at any of the places I have then

Reality tends to be that there'll be a warts-and-all document that only the design team in question will have access to. Someone will get tasked to produce a tidied up version which will then get sent to a dedicated team of technical writers who have no real knowledge of the device and somewhere in that loop it'll go to the lawyers before any sort of document can be made available internally, never mind publicly.

You'll also probably have four levels of document, publicly available, available after signing NDA, internally available and design team warts-and-all. So how much substance remains in the public doc ?

It's also highly likely they'll have some sort of records retention policy to make sure anything that could potentially be requested for a court case gets deleted ASAP.

IMHO, the lawyers probably have more input to the public doc than the design team does!

It might be nice to live in an ideal world where everything was done properly, the world we actually live in is more about protecting IP and maximising shareholder profit. In the eyes of the business people that means something completely different to what the engineers want.

To give you an idea, I've worked places where even employees use google to find the docs. Says a lot about the internal organisation..

It gets better, you'll probably find that nobody at SMSC/Microchip will know what the actual capabilities of the in-built regulator are. Their chip designers won't have designed a regulator from the bottom up, they will have included a regulator from a design library, it will have been specified to have a little bit of headroom over what the LAN9512 requires for its own operation. Beyond that we're into "experimental" territory.

Andrew Warbrick wrote:

Regulators, including the two linear regulators we're dealing with here pretty much always consist of a voltage reference with a feedback circuit controlling a variable resistance between the input power pin and the output power pin provided by either a FET or a bipolar transistor. If the voltage on the output pin is above the reference voltage by more than a tiny amount then the feedback circuit will shut off the output transistor and nearly all the power will be provided by the device with the higher reference voltage. Where it gets funny is when the two reference voltages are very close, both regulators provide part of the power and you can get into oscillations and all sorts of fun and games depending on the impedances around the circuit.

Mostly correct.

But if that "tiny amount" is very very small, or equivalently the gain in that feedback circuit is very large, then even with just ONE regulator, the result will be oscilations. So that's why 1) They don't design for inifinite gain in that stage 2) they specify that (usually 100nF) capacitor near the regulator to stabilize the output.

So, as the voltage on the output drops due to increasing load, the difference between the reference voltage and the feedback voltage increases and the output transistor is driven more and more (to a lower resistance as you say).

The end result is that you can measure a real output resistance on regulators.

You're absolutely right, but the point I was making is that actually pretty small differences in reference voltage result in one regulator of two connected in parallel providing nearly all the current. Yes, the gain in the feedback circuit isn't infinite but it's high enough that you don't need much difference in the outputs for one regulator to be doing nearly all the work. I won't pick nits over the semantics of resistance versus output impedance, you're right, the output does look like a resistor for small changes in load.

I think I already said it a couple of times, that connection to the 1V8 power plane is an ERROR, that needs to be fixed.

The default action from RPF/Distributors for existing users would probably be "screw them", but that problem and the others (again where is the list?) must be fixed to stop screwing new users.

You can theorize and overanalyze what should happen if you put some extra load on those pins, well, if a car wasn't designed to fly, don't insist making it fly...

Connecting LDOs in parallel could lead to very nasty side effects, including oscillation, no proper regulation, decreased output voltage, noise incjection into the core, etc, etc, etc.

About the USB issues, besides what are probably limitations and problems with the actual module inside the SoC and its drivers, until you fix the issues with power and how it is delivered to USB devices, will be hard to do many tests with various devices, it will be just an empirical list of what things work and what apparently don't. I can tell you by a fact that without removing the polyfuses I had a very hard time to make anything wireless work.

-J

I think I already said it a couple of times, that connection to the 1V8 power plane is an ERROR, that needs to be fixed.

The default action from RPF/Distributors for existing users would probably be "screw them", but that problem and the others (again where is the list?) must be fixed to stop screwing new users.

You can theorize and overanalyze what should happen if you put some extra load on those pins, well, if a car wasn't designed to fly, don't insist making it fly...

Connecting LDOs in parallel could lead to very nasty side effects, including oscillation, no proper regulation, decreased output voltage, noise incjection into the core, etc, etc, etc.

About the USB issues, besides what are probably limitations and problems with the actual module inside the SoC and its drivers, until you fix the issues with power and how it is delivered to USB devices, will be hard to do many tests with various devices, it will be just an empirical list of what things work and what apparently don't. I can tell you by a fact that without removing the polyfuses I had a very hard time to make anything wireless work.

-J

jamodio wrote:

 

You can theorize and overanalyze what should happen if you put some extra load on those pins, well, if a car wasn't designed to fly, don't insist making it fly...

+1

There's a reason why engineers devise circuit blocks like LDOs, both conceptual and implemented, and the reason is so that you can black-box functionality and hence ride on the shoulders of giants, instead of crawling along on the ground reinventing everything.  If you break a black box, the giant evaporates and you land on your ass.

Connecting two LDOs in parallel has that effect.  All bets are off.

Fortunately, it doesn't need discussing, as Pete acknowledges the issue.  The only question is what happens now.  As usual RPF is completely opaque on that.

Morgaine.

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."

I see that mahjongg has become an apologist now, and doesn't even realize when he's teaching Grandma to suck eggs.  Sad.  I guess the fanboi disease over there is contagious.

The Foundation has already found the reason for dropped USB events.  No further speculation is needed.

I now find it amazing and enterteining to see that the minions resist to accept that there are problems with the R-pi. "Hey there is nothing wrong with the board, you already tested 12 keyboards, why not 13 ?" and why a kid should carry the R-pi on their backpack ? Some of us minions of the RPF carry it on our underware !!

Sigh ....

Meanwhile I see "no list" or any other info being "shared," and it surprises me that there is not a single bit of information on the main blog site.

As the issues become exponential it will start to backfire, I'd stop production and selling until the issues get fixed.

Meanwhile APC is making progress announcing Newegg.com as distributor for US and Canada.

-J

jamodio wrote:

 

Meanwhile I see "no list" or any other info being "shared," and it surprises me that there is not a single bit of information on the main blog site.

That's what the guy Sulge who got banned at the start of the "USB discussions getting a bit heated" thread said.

He got banned for only a week (perhaps a sign that some admins are starting to realized that the emperor has no clothes), so let's see what he says when he comes back and points out that the very problems he was describing were confirmed by the Foundation's engineers.

Meanwhile APC is making progress announcing Newegg.com as distributor for US and Canada.

Excellent, that makes it a lot more likely that a UK distributor will appear before long.  The APC and BeagleBone are the only two cheap boards with Ethernet MAC directly on the SoC instead of attached over USB, so I'm very favourably predisposed to it.

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."

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

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.

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.

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.