Raspberry Pi - Hardware Flaws and Fixups?

Reviewing the rev 1.0 schematics and docs for the related parts, I found something that looks wrong.

The SMSC LAN9512 has two VDD18CORE pins that are internally connected between them and to the internal core 1.8V voltage regulator, those pins need to be connected externally as well and to a couple of filter caps.

The RasPi schematics shows those pins also connected to the +1V8 power line from RG1.

That looks wrong, the SMSC VDD18CORE pins should not be connected to +1V8.

-J

I fully agree! with your "VDD18CORE" remark.

Jamodio, have you found a "reset" pin on the 2835? The only thing I could find was "run". Would the CPU just pause when pulled low? I don't know.

While investigating this, I found that "D10" is not marked "(B)" as it should. (even though it is involved with the USB powersupply for the model A, the other side is not connected on the model A, so the component is redundant on model A).

jamodio wrote:

 

You are probably right, that interface should be isolated as it was done on the BeagleBoard and Pandaboard. I think that RPF is cutting too many corners trying to save few $$.

I believe the BeagleBoard had revisions A1-A5, followed by B1-B3, before general availability of B4.  So BeagleBoard had lots of opportunities to fix minor issues.  With RasPi there were lots of changes from the Alpha to Beta boards, and the Beta boards had virtually no experience in the field before going to mass production after a very small PCB change.  The BeagleBoard community grew slowly so problems with ICs and Linux drivers could keep up with community growth.  RasPi had an instant community of people with various degrees of experience all buying "developer" boards.  Given all this, I think RasPi did rather well.

jamodio wrote:

 

I'd hope that's the case and will be very helpful for them and for us if they post the design before they commit to a circuit board or go to production.

Unfortunately there's no love for open discussion of design at RPF.  The fanbois over at their forum make it impossible to do over there, and while Pete did open up over here briefly, he's notable by his absence now.

Such a wealth of hardware experience in the community, and no desire to harness it to make Pi better.  I find it very strange that openess is supported for software only, but the shutters are firmly down for hardware.

Morgaine.

John Beetem wrote:

  If this is the case, the few mA shouldn't hurt anything.

Agreed. On the other hand, as noted somewhere else where we were discussing this, the microchip GPIO expander won't do a power-on-reset when the 5V doesn't drop to zero. Now this is first of all a slipup in the specs of the chip from microchip. Their spec says: "to guarantee a power-on-reset you TYPICALLY need to drop vcc to 0V". First they don't mention a max. Vcc has to start at MAX 0V to guarantee a power-on-reset. Secondly, they specify 0V. So 1mV won't work? As you can see with the raspberry pi, there are possibilities of significant voltages throug parasitic means. It is neccessary to know when you need to worry, and when not. On the 'pi we can reduce the 1.7V to about a milivolt by adding a 1 Ohm resistor between 5V and ground. 25W of extra power during normal operation, but not good enough to satisfy the microchip datasheet spec.

I really find it very hard to understand their attitude, and I had my dose of argument exchanges with some people over the forum and the blog.

Since I joined the "community" I felt that there is a tendency to overreact and respond in a defensive mode, my opinion is that if somebody makes a comment about something wrong about the Rpi or RPF is not to diminish the work that has been done or taint the "product", au contraire, is to make it better and stronger and contribute to the actual end goal of the entire project.

The typical response is "YOU must be doing something wrong" everything is rosy and works fine, it feels like instead of trying to build a "community" what is being forming is a cult.

I hardly doubt that the secrecy around the hardware design is to protect Broadcom IP. I've the impression that you have been in this industry for a while, so you must probably know that nowadays any company or entity with the capital and brain power to compete with Broadcom has the ability to reverse engineer their chips to the last atom. I understand NDAs (work every single day with them) and some of the reasons to protect/restrict some information, but we are not asking here for the VHDL source for the GPU or complete documentation, just the basic stuff.

Yes the BeagleBoard went through several revisions, as many other similar developments, but there are some stuff like this VDDCORE pin issue that would have been detected sooner if the schematics were public before, I don't remember RPF making ANY of the previous revision schematics publically available.

Perhaps more focus and energy is needed on design and review and much less on promotion and hype, I'm sure we will all cheer together and generate hype and buzz for the Rpi.

I agree with you Morgaine, the intention here is to make it better.

-J

"On the 'pi we can reduce the 1.7V to about a milivolt by adding a 1 Ohm resistor between 5V and ground. 25W of extra power during normal operation, but not good enough to satisfy the microchip datasheet spec."

I asume you are joking right ?

The voltages are no "parasitic", just product of not good design IMHO.

Like asuming that cellphone chargers are a good option as a power supply for the Rpi.

-J

What I'm trying to say is that if you TRY to design a raspberry pi-with an MCP23017 and would like the MCP23017 to power-on-reset, you HAVE to reduce the powerline to ZERO to get any type of guarantee from microchip that the chip will perform the reset.

So even if I were to install a 1 ohm "bleeder" resistor to ground, I'm guessing the voltage on the powerlines with no powersupply but with an HDMI screen connected will be about 1 mV: There is a 1800:1 resistordividor between a 5V and the raspberry pi 5V. It can be 2 or 4 mV for all I care. But that won't make the board achieve the microchip specs and it WOULD increase power consumption during normal operation tenfold.

In short, the microchip specification for this chip is unworkable. Bad specifications.

The problem probably lies in the SPECIFICATIONS. Not in the chip.

And then we'd be using a "typical" value from the datasheet, so in practice, microchip tells you these chips will perform a "power on reset" the first time from the factory, and all bets are off after that....

It's not easy to write good specifications. It's not all that hard either. Broadcom are better at it than Microchip. The broadcom datasheet for the BCM2835 nicely states for unimplemented bits: write zero to allow for upgrades to the chip from our side. Those are the things that make a datasheet worthwhile.

I remember from a long time ago, datasheets that used to mention: 'minimum hold time' for an output. They specified that the chip wouldn't change the output for XXX ns after the clock. This means that they have themselves in trouble: Suppose they can make these chips 2x faster. Alas, they cannot sell them under that datasheet: they won't meet the minimum hold time. And their customers are in trouble. Suppose a design trusts the minimum hold time. But 10 years later the chip needs to be replaced and is replaced by a faster chip, possibly from another manufacturer. Big trouble.

Bad specifications cause trouble. This part of the microchip MCP23017 datasheet can be considered such a bad specification.

This is a bit of a non-sequitur I know, but for some reason your mention of MCP23017 made me think of how much more massively expandible Pi would be if the CSI/DSI board area were replaced by the cheapest Cortex-M0 and some more headers.

Morgaine.

That wouldn't pay for EU bonus at Broadcom

Knowing how to tell your company to sod off without losing your bonus is an essential engineering skill.

I'm not so sure that the power line has to be reduced to zero to be assured of a POR.  Whilst they state "VDD Start Voltage to Ensure Powe-on Reset " = Vss they also state this hasn't been 100% tested, the Vdd supply has to be above 1v8 for the device to work, and as Vil = 0.2 * Vdd = 1v1 @ 5v5 an assumption could be made that anything below 1v1 is considered as 0 < Vss <1v1.

True they don't say this but so long as Vdd rises no faster than 90ms from zero to 1v8 a reset ought to occur or 35ms. from 1v1 -> 1v8.

I'm not so sure that the power line has to be reduced to zero to be assured of a POR.  Whilst they state "VDD Start Voltage to Ensure Powe-on Reset " = Vss they also state this hasn't been 100% tested, the Vdd supply has to be above 1v8 for the device to work, and as Vil = 0.2 * Vdd = 1v1 @ 5v5 an assumption could be made that anything below 1v1 is considered as 0 < Vss <1v1.

True they don't say this but so long as Vdd rises no faster than 90ms from zero to 1v8 a reset ought to occur or 35ms. from 1v1 -> 1v8.

Oh, sure, you can make assumptions on how YOU think the device works  and then draw your conclusions from that. But why do you have a datasheet then when you're going to assume specifications anyway?

The datasheet is there to

* Provide workable design guidelines for the designers.

* provide testable parameters for production testing.

* form a sort of a "contract" between a chip producer and a PCB designer.

Suppose a datasheet says:

V_in_low           max 0V

So this is a bit better than in the microchip datasheet: we have a testable limit. But it is unworkable for a designer.

Suppose the line is connected to a pullup. Say a 1k8 pullup to 5V.

Suppose I have an AVR (which has one of the biefiest output drivers around!) that drives the pin low. The output resistance is about 25 ohms. The voltage will end up at 68mV.

You can start guessing that most chips will accept a voltage below about 0.5 VCC as low, with the absolute lowest value that might be recognized as  a 1 being 0.3VCC. Sure. You're probably right. But WHY is there such a weird spec in the datasheet? Why don't they just say:

Maybe they made a mistake, and by documenting it in the datasheet: "its a feature, not a bug". Now if someone gets "bitten" by this, they get to say: Did you read the datasheet?. And they get to fix it at their own leasure, while producing and selling the chips.

Of course, this is not desirable if the "bug" is big. But if it is something that might effect less than 5% of the customers? They will surely try to sell the chips.

Different field. Same thing. I fly paragliders for a hobby.

They come in different sizes. For example "small", "medium" and "large", for different weights of people. So each has a weight-range. These things are tested by an independent body for their safety. But only within the weightrange given by the manufacturer.  So a small will be for 65-85kg, the medium 80-100 and the large 95-120 or something like that. The safety test has been performed for the medium at 100kg, and it COULD in theory be a dangerous mean *** at 101 kg. Not likely, but the tests don't give any guarantees outside the official weightrange.  All the weightrange numbers are round numbers, 5kg overlap between sizes.

Now suddenly a new model is announced. The weightranges end up having just 1kg or even 0kg overlap, and the ranges are suddenly values like 82 - 97 kg. That makes you wonder why they didn't just make that 80-100? Did the glider fail the tests at 81 and 98 kg? Nowadays I know enough about these things that I'm willing to be a "test pilot" for these things. But that's just me 99% of the people should stick with the specifications.

So, back to the chips. Given the specifications you cannot rely on the power-on-reset. Maybe it will do the power-on-reset, maybe not. The device is probably usable, but the values mentioned as "power on values" should not be trusted. Initialize everything you want in a certain way.