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

As there is a resistor on the "run" pin, I'm pretty sure the signal can be found on the "outside" of the PCB.... But getting a replacement 'pi is not yet easy and cheap enough for me to start testing this. Pete has the full datasheet and he can figure it out.

Very interesting observation about the VDD18CORE pins.

Can you tell what symptoms this might cause?

It is likely that it doesn't have any bad consequences. However it goes against the intention of the chip maker, so you're effectively beta-testing the chip. There just MIGHT be weird effects that nobody had expected.

Some people claim that it is bad practise to connect multiple linear regulators in parallel. Which is what we're doing here. Some hobby-RC electronics (Electronic speed controllers) have four linear regulators on them and connected in parallel. Someone reported that these start to oscilate when unloaded. Everything was fine when a little current was used. He disconnected three of every four regulators and all was fine.

So: We risk oscilation. We risk injecting noise into the lan9512 chip where it isn't expected.... (or the other way around).

Unfortunatelly there is not much doc available for the BCM2835.

The electrical characteristics on the LAN9512 DS do not make any mention about those pins, then I'd infer that the only reason for their

existance is for the external caps for the internal regulator like many other devices. So those pins are not intended to be an input from

an external 1.8V source nor an output to become a 1.8V source.

Besides injecting noise on the core voltage, it really depends in which direction current is flowing at any given time, so extra current

draw from the internal regulator or additional current flowing through those pins will probably increase the chip temperature, and

since those pins are not intended to be connected to anything active, the silicon probably has not much protection, so potentially

you could damage the chip.

I don't know what consequences it may have on the BCM chip.

In summary, I don't believe it is something that will make the board blow up but MUST be corrected on future revisions, the way it is

right now it is simple wrong.

I'll see what happens if I pull down RUN.

Right now I'm testing the Arch Linux distro, Debian seems to have another issue on the kernel related probably to the USB/ethernet

driver.

My .02

-J

It's not connected to the BCM2835 1.8V regulator output: The BCM2835 doesn't have a 1.8V regulator.

The 1.8V comes from the RG1 regulator. (Ah! This means we'd be able to run 1.2V SDRAM!), but as things are right now, it'd be a funny experiment to remove the NCP1117 altogether and see what happens. :-)

When the 9512 has some "headroom" and/or the SDRAM interface doesn't use too much power on the 1.8V line, this would save a few components for the foundation/farnell/RS.

I though that the 1.8V regulator was the smallest of the three, so that the "design power" of the regulator was probably the lowest. Not true: RG1 is the middle one. So Pete problably thought a noticable current would flow there....

(The FT232BM had a 3.3V regulator on board, which could deliver 10mA of extra current. Useful, but quickly inadequate. The FT232RL has a 3.3V regulator with 50mA to spare! That's quite useful. You can easily power an AVR and a few leds from that!).

Yes afaik there is no internal regulators on the BCM2835.

The LAN9512 pins are connected to the main 1.8V fed by RG1 wich feeds the BCM2835 1.8V, several clocks and PLL circuits, the USB module, etc.

Those pins are not intended to be an OUTPUT just a connection point for the required filter caps.

I've no clue what is the total current draw by the BMC2835 through those pins.

I don't think it would be a good practice, even to try, sourcing the 1.8V from the LAN9512 pins. And for model A you will sill need the 1.8V regulator.

The NCP1117 can provide up to 1A (obviously not in this application), it shows about 95F so there is some current flowing there.

I guess Pete has the advantage of seeing all the BCM2835 documentation that is not available publically.

-J

jamodio wrote:

 

Yes afaik there is no internal regulators on the BCM2835.

not true... There is a switching regulator IN the BCM2835 that generates the 1.2V core power its own use!

C16 and C17 next to the SOC are involved (input/output capacitor) and directly opposite on the bottom side of the PCB, L5.

Suggestion for the future....

You know those pins that power the SD interface voltage? The one that was left floating in the alpha batch in january? That should become jumperable to 1.2V or 1.8V. That opens up a few new RAM chips.

In fact I think I have a 'pi that has a 1.2V RAM chip installed where this voltage is SUPPOSED to be 1.2V. Not 1.8V.... (On the other hand, the RAM chip that I have also needs 1.8V, and I don't know which is which..... In january I thought the missing connection was the one for the IO buffers on the chip, which I THINK are supposed to be 1.2V for my samsung K4P2G324ED. And from the schematics I cannot see what voltage would be present on SDRAM_VDD.) (*)

Oh, in the box "PWR1" at the top of page 1 of the schematics, you see several "voltage regulator outputs" on the BCM2835.... :-)

(*) On the other hand, the pins marked 1.8V are probably really 1.8V, and really power the SDRAM chips themselves. while the SDRAM_VDD might be the one that is the IO voltage for the SDRAM and be the 1.2V that the Samsung page mentions as the VDDQ, the IO voltage for the SDRAM chip.

You are absolutely right, didn't look in detail at those pins !!

I t would be nice if Broadcom at least releases the pinout documentation with a brief explanation of what each pin does.

-J

So no follow ups, additional comments about this issue ?

What issue are you referring to? The pinout datasheet? You say "it would be  nice... ", and I agree. But it is not going to happen.

Perhaps ask them nicely for informally documented pinout information?

At worst they'll either refuse or just ignore the request, but you never know.  We might be hugely and pleasantly surprised.  It's summer after all, and Broadcom might have some interns kicking around the lab looking for something simple to do.

In addition, there's another possible outcome lying somewhere  between the best and worst cases, which is that certain Broadcom employees who regularly post on the RPF forum will probably come out with elaborate rationales about why pinout information must be protected at all costs otherwise it will reveal the deepest secrets of the company to the competition.  That would be worth its weight in gold for sheer comedy, so please ask.

Maybe someone should ask Where's Pete?

Last we heard, back in April he was going to release v1.1

of the schematics "soon".    After seeing 100% of the

foundation's paid staff (Myra) disappear without any

announcement, I get nervous when key people like Pete,

who was quite active on this forum, go off to fixup the schematic

and don't return.  I think the Model A was also his baby,

and has disappeared from radar.  And as we know, Seneca was

going to fix the login and timezone problems in Fedora 14 back in

March, and from what I can tell, Chris Tyler is off writing a book,

and his student helpers haven't been heard from lately. 

Maybe someone should ask Where's Pete?

Last we heard, back in April he was going to release v1.1

of the schematics "soon".    After seeing 100% of the

foundation's paid staff (Myra) disappear without any

announcement, I get nervous when key people like Pete,

who was quite active on this forum, go off to fixup the schematic

and don't return.  I think the Model A was also his baby,

and has disappeared from radar.  And as we know, Seneca was

going to fix the login and timezone problems in Fedora 14 back in

March, and from what I can tell, Chris Tyler is off writing a book,

and his student helpers haven't been heard from lately. 

Combining the last two messages into a "glass half full" kind of explanation, with a bit of luck Pete's not here because he's massively busy redesigning Pi v2 with better thermal and power management.

It has to be done, the only question is when.  Far better to do it sooner rather than after the world is flooded with marginal boards, IMO.

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.

There is another issue that I believe it has been already reported and I can see now that I've the gear hooked up to the Rpi.

There seems to be some leakage from the HDMI interface to the 5V line, a voltmeter without a power supply connected but with the HDMI connected to a Samsung SyncMaster B2330 shows about 1.45VDC, that goes to 0VDC when the HDMI is disconnected, that voltage shoudn't be there.

-J

jamodio wrote:

 

There seems to be some leakage from the HDMI interface to the 5V line, a voltmeter without a power supply connected but with the HDMI connected to a Samsung SyncMaster B2330 shows about 1.45VDC, that goes to 0VDC when the HDMI is disconnected, that voltage shoudn't be there.

My guess is that leakage is from HDMI_SDA and HDMI_SCL through 1.8 K resistors R13 and R14.  They probably provide enough current get the SoC and/or LAN9512 to the point where they first start to turn on, but not enough current to get any further.  If this is the case, the few mA shouldn't hurt anything.

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

-J

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.