Raspberry Pi - Hardware Flaws and Fixups?

Now that people have actually started receiving the boards so the design in final, is the schematic close to being posted?  I looked around again in various likely places just now, but haven't spotted it yet.

actually, the design may not be quite final yet.  Liz said: "Happily, we’ve found it doesn’t need a shielded enclosure to reach Class B, although it will require a (very minimal) redesign." http://www.raspberrypi.org/archives/978, page 3, April 10, 2012 at 7:04 pm.

It hasn't been announced when such a change might be implemented, but probably better sooner rather than later, given the large production runs planned, perhaps along with a change to fix the SD card voltage issue.

Hi  All

Schematics - Yes we have had a discussion on this and there are a set in the release pipe and they reflect the current status of the delivered boards as of today.  Will post back here as soon as they are ready for download on the raspberrypi main site ( I know Liz and Eben are still running round like mad things).

The Pi board has a set of 4 hard links that can be read by the firmware so it knows which version of the board it has and can configure accordingly.  However, anyone who is doing something more than just software needs to know what may change (e.g. GPIO) so they can plan for it. We have a candidate list and this will be published soon but now separately from schematics.

Bright LEDs - They are, we will look at dimming them down but some people who are designing cases want to use light pipes of some sort and this makes them harder to see if they are not 'bright'.  Guess we could save some power?

Cables - we have not seen a problem with any of the ones we have been using - or reports from developers, BUT now we have a population of more than a few hundred I can see issues like this appearing.  We just need to work together to pass around knowledge.

More later - need to dash.

Pete

Roger,

  That's an interesting observation that the micro USB connector may have been

substituted for a cheaper surface-mount one.  Paul Maunders, with beta board #8,

commented on how rugged the power connector felt:

but GizmoB73, with a production road-test unit commented just the opposite.

Now that apparent conflict makes sense.

After the ethernet jack issue, it makes you wonder if any other substitutions were made.

FYI, I've powercycled my RPI about 100 times yesterday, but I always use the connector on the other side of the power cable. This way my RPI doesn't wear down, and I can start over with a new $3 USB-power-cable after the second insertion on the RPI....

I power cycle mine a lot too, and I really wouldn't want to put all that strain on the Pi's power connector either.  I always disconnect the power further down the line.

Pete, I guess the schematics would tell me this, but do you know if the Pi supports the type of high current connections that Ipod/Ipad do?  i.e. a resistive connection to the D+ and D- pins?  If so, there might not be so much of a voltage drop if we have current going through all four wire (albeit smaller on the D- and D+ wires).

Gizmo,

Those voltages on D+ and D- are not power-carrying.
Apple wanted to make a powersupply that provided 1A of charging current, but didn't want to be breaking any 500mA standard-USB power-sources. So they decided that 2.0V on D+ and 2.7V on D- will indicate that this is a 1A capable apple charger.

This is an easy and cheap way to identify the charger. It's just identification.

The D+ and D- lines on the Micro USB connector are not connected to anything on the RPI.

-------------------

Pete, Not sure if you've heard about this, but some people are a bit disappointed that I2S has been dropped. So those are planning on using those strapped pins as access points for the I2S hardware on the SOC.

If another "board revision" possibility presents itself, that might lead to less problems for those people.

I was thinking about: The GPU already knows its serial number/MAC address. So could that be used? You guys have 1M mac addresses, right? So if you reserve the top two bits for board revision, you're leaving some 150k mac addresses unused if the current "batch" of 100k boards are rev 0, and the next will be rev 1.

Or if that sounds wasteful, the mechanism for "personalizing" the SOC that is used for the MAC address can also be used for passing BOARDREV=XXX on the kernel commandline.

On the other hand, that would require a ROM firmware upgrade to the SOC, right? Is that really ROM? Flash? OTP?

Thanks for the update Pete. Can you provide some detail about what changes are required besides the HDMI configuration in firmware ?

Do these changes require a pcb layout redesign ? (Perhaps your opportunity to move that eletrolytic)

Also, does anybody has any piece of concrete information about how many boards have been actually manufactured and shipped out from the assembly house in China?

Thanks & Regards

All

As a follow up to my previous post here is an X-Ray of the Micro USB.

Sorry about the funky colour scheme but it hard to pick out the tabs from a lump of solder (lead free) around them (blue in blue).  You should be able to see that the tabs are present and will resist the lateral force applied.  They are not as tall as the thickness of the board as they are primarily used on very thin laminate (0.6mm) and we are at 1.4mm.  I should also mention that we are looking from the back through the PCB.  You can also just see below the tabs, the green area with yellow flecks; that is the two solder pads under the front of the connector, and they seem to be reasonably well soldered.  The voiding (yellow flecks) are normal some better than others.  The orange tubes to the left are vias in the PCB.

I'm sure if we get any failures of this component I'll be the first to know, because you guys will tell me.

I think I'll go an chase some of these posts on power issues relating to duff cables and 'suspected' duff polyfuse parts.  Let you know what I find.

Pete

Thanks for the microUSB x-ray, very informative! Will look forward to more updates. And meanwhile, this is a cautionary tale:

http://www.raspberrypi.org/forum/general-discussion/close-call-nearly-bricked-my-rpi#p66238

Hi Pete,

If you're interested, I would think that people who are having troubles are using a power cable or power supply that isn't good enough.

You must be aware that I and others have measured cables at 3-5 Ohms. That is surely not going to work out well.

I haven't measured the average current yet, but it could very well be about 0.3A. With a 1 Ohm cable and a 5.1V powersupply that would lead to the 4.8V that someone measured with a multimeter.

However a burst of 0.7A will then deplete the 220uF in under half a millisecond. (I'm assuming a 0.7V dropout for the 3.3V regulator). That's way too fast to measure with a multimeter. And it's way long enough to brown-out the CPU and/or LAN chip.

Roger & All

I'm seeing a few issues relating to this 'brownout' problem.  I've got someone looking at this with fast scope and a selection of cables / PSU's to try to bottom this.  We have not seen this problem in our test set but that is the joy of putting something in the field.

I'm also trying to get a handle on the population of users that have a problem with this.  Interestingly in one of the tests we did is to run the board w/o the 220uF present and it still worked without problems - so you could be onto something.

Thanks for the input.

Pete

Roger & All

I'm seeing a few issues relating to this 'brownout' problem.  I've got someone looking at this with fast scope and a selection of cables / PSU's to try to bottom this.  We have not seen this problem in our test set but that is the joy of putting something in the field.

I'm also trying to get a handle on the population of users that have a problem with this.  Interestingly in one of the tests we did is to run the board w/o the 220uF present and it still worked without problems - so you could be onto something.

Thanks for the input.

Pete

Thanks for all the info Pete. A summary of possible 'minor' hardware changes that I've spotted in the forums:

1. I2S implement  as per the data sheet

2. SD card voltage option bank change, as per Dom's posting in: http://www.raspberrypi.org/forum/general-discussion/where-is-the-bottleneck#p62401

3. USB OTG Id Pin to spare GPIO pin (effective only on Model A) as per:

http://www.raspberrypi.org/forum/features-and-requests/cheap-but-crucial-model-a-feature-request-read-this?value=gpio%20usb%20pin%20request&type=2&include=1&search=1&ret=all

I'm not sure if the next two are technically possible!

4. Assisting POE (spare wires variant) adaptors exist that inject power onto the unused lines of ethernet and then split them out again after a cable

run see: http://www.cjemicros.co.uk/micros/individual/newprodpages/prodinfo.php?prodcode=4D-RPI-POE-IS-C (The Raspberry Pi adaptor cables doubles the price!) but if R-Pi's RJ45 could be changed for a variant that took the extra lines Earth to R-Pi's Earth and the Injected Power lines to R-Pi 5V via a link.

Pros: simple for end users to setup and injector only cable should be cheap.

Cons: POE variant of RJ45 with magnetics needed [1], cost, Reduced Isolation and extra link needed.

5. Assisting POE (via GPIO daughter board) If a POE daughter board was plugged into the GPIO pins with the daughter board having a POE input

RJ45 on it, supplying power to the R-Pi. The four ethernet data line output from the daughter board being connected to currently unused GPIO pins. I suspect inputting ethernet via the GPIO pins breaks various rules and could add to RF output:-(

Original suggestion at: http://www.raspberrypi.org/forum/features-and-requests/routing-ethernet-pins-4578-to-the-expansion-port

[1] I found a mag jack that might the type needed at: http://www.adam-tech.com/catalog/2012/page_009-049.pdf

See page 37 of 41 (marked Page 45) layout M16

n.b. I'm intrigued, what do the two diodes on the underside near the USB sockets protect?

I'd thought the USB ports, but people have mentioned on the forums that they have (unreliably) powered R-Pis via one of the two USB ports.

mmm, I really hope those "power issues" turn out to be just bad cable/adaptors/ppl doing it wrong.

You guys are working on it I suppose.

btw PeteL, what is requiring redesign (for full compliance)? That's what is bugging me, since it leads to another question: when will this be implemented (and then re-certified)? Before or after the queue of orders?

I guess "what are the changes needed" is more your cup of coffee (or better tea), so that's what I'd really like you to enlight me on.

Btw, is it just me or those 2k units feel a lot like a pre-serie?

"those 2K" should be "those 10k". The other 8k are Guaranteed to be exactly the same: they were produced feb-march just like the first 2k that are delivered right now.

and yes, I too would want to know what changes seem to be neccessary and when they will go through.

What is the HD interface? (schematics P4 left top)

What value is typical for the built-in pullup/pulldown? I expect that to be on the order of 50-100k. In that case you can encode 3^4 different board revisions with the 4 board-revision strap resistors:

read value. If zero, enable pullup, if one enable pulldown. If value now changes, the strap is left "open", so that's the third value.  (Ah! found them!).

There is an error in the schematics. p3 mentions the "USB" part of the LAN9512 as "model A only". That should be "Model B only" of course.

R22-R25, R28, C28 are missing their "Model B only" tag.

Why is there a line going from R25 to R22?

Due to space constraints the 100M led is labeled 10M on the board. How about calling that "FE" for "Fast Ethernet"? That's what 100M was called back in the days.

On the other hand, I would much rather have a BCM2835 GPIO pin control a led in that position. If we want, we can program it for the 100M/FE function in software, but it provides those who are going "bare bones" with an extra debugging option.

Similarly, the FDX led is nowadays a bit outdated. Why on earth are we still interested in that statusbit? Any reasonably recent setup will run full duplex, and it won't help in debugging in seeing that led remain off. Again: A gpio LED would be a nice replacement. The easiest way to notice a halff duplex link is to watch "dmesg": smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1

What is the purpose of D15, D16? I'm thinking: Protection against static discharges, right? The question is: Wouldn't it be better to connect their kathode to +5V0 instead of +5V0_HDMI? The +5V_HDMI is just a small net that only has the 100N C75 on it....

Are the HDMI_SDA and HDMI_SCL pins 5V tolerant? I wouldn't have guessed.

On the other hand, I would much rather have a BCM2835 GPIO pin control a led in that position. If we want, we can program it for the 100M/FE function in software, but it provides those who are going "bare bones" with an extra debugging option.

 

Similarly, the FDX led is nowadays a bit outdated. Why on earth are we still interested in that statusbit? Any reasonably recent setup will run full duplex, and it won't help in debugging in seeing that led remain off. Again: A gpio LED would be a nice replacement. The easiest way to notice a halff duplex link is to watch "dmesg": smsc95xx 1-1.1:1.0: eth0: link up, 100Mbps,full-duplex, lpa 0xC5E1

I agree with that, FDX led is not really usefull, it would be much better if that could be used as a gpio led.

That way you can directly let kids program the led without the need for extra hardware.

Hans

Well, in principle you can use the FDX as a GPIO LED.  The difficulty is that you need to talk to the LAN9512 in USB-speak to configure and toggle it, and the driver may make this difficult.  Still, students would learn a lot about USB drivers trying to do it :-)

Was it here that someone asked me to measure the physical size of the 'pi? Mine is 55.9 x 84.9mm.

Yes me...  thx Roger.

Hans

I know it is only slightly different, and may not matter at all, but in a post on the Raspberrypi.org website one recipient (another case manufacturer actually) has said that: The board is 85.00 x 56.17

Hi David, yes I know   ModMyPi measured that....  That is why I asked Roger... I know he is very precise...

So probably the pcb board is 85.0 x 56.0  with 0.2 tolerance

All my cases are made 85.6 x 56.0, and I have 4 lying here waiting.... but I was not that lucky in getting a Pi...

So the pcb will fit,  even if it is .17 wider I can probably shave a little off the pcb board...

Hans

The schematic doesn't appear to show the memory chip-select lines,

but Gert has mentioned that the SoC has only a single chip-select line,

which prevents stacking more than one memory chip, as described here:

http://www.engadget.com/2011/03/25/samsung-starts-baking-30nm-4gb-lpddr2-chips-packaging-2gb-mobil/

Are the production volumes large enough now that Broadcom might consider

presumably minor changes such as adding an additional chip-select line?