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.

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 you wrote: "However next in line is my I2C interface. This too is labeled on the GPIO port as: I2C SDA, I2C SCL, and I'll have to guess which of the several I2C interfaces is connected to the GPIO pins"

The wiki says the I2C are SDA0 SCL0 !

Are planning on doing an I2C driver?

I have a batch of Real Time Clock modules that I'd to love to start selling but would like to get them tested on an R-Pi first!

Or is anyone else with an R-Pi /getting in the next batch, interested in writing an I2C driver? If yes please email me: chris@cjemicros.co.uk

I'm told that the Linux sources have a driver for the DS1338 that I've used! (there is also support in the RISC OS sources which is how we have tested our design)

Roger you wrote: "However next in line is my I2C interface. This too is labeled on the GPIO port as: I2C SDA, I2C SCL, and I'll have to guess which of the several I2C interfaces is connected to the GPIO pins"

The wiki says the I2C are SDA0 SCL0 !

Are planning on doing an I2C driver?

I have a batch of Real Time Clock modules that I'd to love to start selling but would like to get them tested on an R-Pi first!

Or is anyone else with an R-Pi /getting in the next batch, interested in writing an I2C driver? If yes please email me: chris@cjemicros.co.uk

I'm told that the Linux sources have a driver for the DS1338 that I've used! (there is also support in the RISC OS sources which is how we have tested our design)

Hi Chris,

I've gotten I2C working now from the commandline "bitibanging" utility. I was just browsing around on the forum to find a place where I can post a link to the software. :-)

Which reminds me: I don't have I2C read implemented yet....[time passes] .... OK. Done! :-)

Here are the commandline utilities to control GPIO, SPI and I2C.

http://www.bitwizard.nl/software/gpio_spi_i2c_20120419.tgz

Some sample scripts are included to make it easy to work with my I2c and SPI boards.

I'll start looking into writing the I2C and SPI kernel drivers shortly.

It could very well be that I decide that what I want from a kernel driver is not what the standard I2C and SPI kernel drivers do. I want to be able to easily, from userspace, interact with the devices on the bus. Eventually it should be something like:

echo 1 > /dev/motor

and the motor starts turning. :-)

OT: Chris, your name sounds familiar. Were you involved with Linux in the early years? Google shows that there is an actor with your name too. (or is that you?) :-)

Great work Roger! I've emailed you via the bitwizard site.

There are a few Chris Evans's about. I'm new to Linux!

Ha, I already wondered how long it would take you, to show something like this....

I think it is a good picture for the frontpage on raspberrypi.org....

Can you perhaps measure the pcb for me. I am getting different answers from people.

Best guess now is  85.0 x 56.0   or  85.0 x 56.2

Hans

Observation about USB power supplies: not sure if relevant to RasPi or not.

I was making some load measurements on a bunch of 5V USB power supplies here, unrelated to RasPi stuff. Got some confusing results, until I realized something I didn't know: some of those cable-less "wall wart" USB power supplies with just a USB jack, connect the internal ground pin (cable black wire) to the connector shield (cable braid), and some do not. So in some cases you'll have the ground return current flowing on the shield (if your device connects ground and shield) and in some cases, not. In case of interest.

Did you end up trying your DS1338 RTC board with with Pi? 

It looks like it can operate at 3.3V so no level conversion is needed.  I've hooked up the DS1307 RTC with bootc.net's Linux 3.2 image and it worked well.  But I'm interested to switch to 3.3V part so avoid the wiring mess.

Drew, I didn't even realize that Element 14 had their own blog system until you posted this, and that people were replicating RPF's blog posts to it.

That could be very useful, since it allows commentary without their petty censorship, and it overcomes the Foundation's continued attachment to Wordpress which has always made navigating their blog a pain.

If you're willing and able to recompile the kernel, you can add some platform data and have the kernel read the rtc and set the date and time for you. This removes the need to use hwclock and binding the driver to the correct i2c address. It's possible to add platform data for all sorts of i2c devices so that they come up automatically on boot, regardless of userspace.

One of my projects is to add an RTC and a GPS with PPS output to my Pi and turn it into an NTP server.

Yikes, I've read about IP address bans and just realized that might mean a user wouldn't be able to even read the RaspberryPi.org blog, is that right?

In general, I'd love to see more members of this group post in the group's blog about any Pi projects/tinkering they might be doing.  I'm going to post about another I2C device shortly.

That sounds very exciting!  I'm going to have to try that.  The attraction of the Pi to me is being able to meld my electronics tinkering with the kernel I've been running for so many years - and learn more about how it works at a lower level in the process.