EEVblog #716 - Raspberry Pi 2 Xenon Flash Problem Explained

[ConKbot]

No datasheet on a buck converter did someone pay On-semi to develop said controller, and doesnt want it released? I can kind of understand (or i guess more accurately, have gotten used to) broadcom being uppity about their datasheets, but wtf on a smps IC. 

[tom66]

No datasheet on a buck converter did someone pay On-semi to develop said controller, and doesnt want it released? I can kind of understand (or i guess more accurately, have gotten used to) broadcom being uppity about their datasheets, but wtf on a smps IC.

Lots of new vendors do this. Sometimes they don't want other manufacturers to make second source parts, which introduces price competition. Much harder to make a second source part without a complete datasheet.

[Ketturi]

When I was kid, I used to toy around with flash and cheap toys and calculators, I managed to erase eeprom or something from currency converter calc and so on. Ordinary glass encapsulated SMD diode could be used as flash detector too (any diode is photodiode as Dave showed). Also, descent flash tube has enough light energy to slightly melt thin black plastic used in floppy disks, tested that too. I wonder if flash light could be used as some kind of debugging method...

[senso]

In laptops its a misery, almost all the recent(newer than 2012) switchers from TI from the BQ family there is no even a draft/preliminary datasheet, one of them is used since 2012 and in the site it says that the chip is in preview, awful to debug the board with no datasheets 

[Howardlong]

It does seem rather counter intuitive to keep data sheets under NDA particularly for commodity parts like voltage regulators. If they're only interested in 6 figure plus volumes I can just about see why there's some reticence, but for the designer it's a reason to not even bother evaluating. In the end, I'd say that especially for jelly bean parts like these, it makes no sense.

[ConKbot]

but for the designer it's a reason to not even bother evaluating. In the end, I'd say that especially for jelly bean parts like these, it makes no sense.

Hmm, browse a preview, and have to deal with an NDA, or hit up TI and use the webbench and have 15 functioning circuits handed to me  That I2c interface better be really slick to justify the hassle 

[mux]

WLCSP packages are always supposed to be underfilled in commercial applications. Look in your phone, look in any kind of tight-space electronics and you'll see underfill even around PCB-based BGAs. Both to keep light as well as moisture out, because both can be a real pain.

This is just a major fail on the part of the foundation, and kind of shows (as if we didn't know already) that the layout guy(s) is an amateur. They shouldn't try to design this stuff themselves, just hire a proper system designer.

Where did you get that they are supposed to be underfilled? Actually most of them usually are not underfilled on the mobile phone PCBs. Depends on the phone model and manufacturer, for example, Nokia did underfill very rarely and only 1-2 biggest micro BGA chips on the entire PCB. Samsung on the other side did underfill a lot, often with transparent compound.
I don't see this to be a failure or reason to blame someone at all.

I have honestly never encountered a non-underfilled wafer-level package. All WLCSP packages that I worked with or inspected in the past had links to documents describing exactly if and how they should be underfilled. This is a big part of the selection process, too, as packaging doesn't exist for no reason. If you buy an (essentially) unpackaged chip, you generally need to compensate in some respect for the lack of packaging in other ways. So it's either: buy a $0.02 more expensive chip with the packaging and leadframe or spend money on underfill. This is basic component sourcing and layout engineering.

The only reason not to underfill would be if you'd do the systems engineering and decide that no, this application will not encounter the problems associated with unpackaged chips. No moisture, no light. If light isn't an issue, small chips are often not underfilled because moisture can easily diffuse from out of the balls (/r/nocontext will probably quote me on this), but big packages still get underfill. This could very well be the design decision of Nokia in the case you describe. But for the Raspberry Pi, obviously this board will be used bare and in normal consumer environments a lot, so I cannot see why an engineer who is aware of these issues could think it would be a good idea not to underfill. That is why I'm so adamant on the failure of engineering here.

[vlad777]

That clamping chip near the HDMI probably has reverse biased diodes between rails.
This is exactly the configuration when you expect photodiode to react with light, to conduct.
So that chip is overloading the SMPS and creating dip in voltage.

(Raspi did reset until Dave covered the HDMI chip.)

[Monkeh]

That clamping chip near the HDMI probably has reverse biased diodes between rails.
This is exactly the configuration when you expect photodiode to react with light, to conduct.
So that chip is overloading the SMPS and creating dip in voltage.

(Raspi did reset until Dave covered the HDMI chip.)

It's almost certainly not even on the same rails..

Please people, stop jumping to silly conclusions about things which have already been tested properly.

[vlad777]

That clamping chip near the HDMI probably has reverse biased diodes between rails.
This is exactly the configuration when you expect photodiode to react with light, to conduct.
So that chip is overloading the SMPS and creating dip in voltage.

(Raspi did reset until Dave covered the HDMI chip.)

It's almost certainly not even on the same rails..

Please people, stop jumping to silly conclusions about things which have already been tested properly.

It is not jumping and not silly. I give you some theory and some evidence.
I am sorry I don't have raspi to confirm or debunk this idea.

[Mad_with_Power]

A crude analysis of the effect of wavelength on the RasPi Xe flash problem:

I thought the higher frequency light emitted would be the culprit, but a 5mW 405nm (deep violet) laser did not affect the chip at various angles or focus ranges including a pinpoint dot.

However, a 110mW 532nm (green) laser, even at wide focus ranges (lower intensities) consistently caused the Raspberry Pi failure.

My next thought was that since 532nm lasers are frequency doubled in a crystal from a 1064nm (IR) diode, there could be IR leaking through and causing the effect. I had the output analyzed and found less than 5mW in the IR region which should not affect the chip at the very wide focus because it is about as intense as a typical IR LED. I then tried using a remote with an IR LED and confirmed that the IR in the laser was not the cause.

Also tried were: blacklight, 650nm (red) 1mW laser pointer, and xenon strobe though a >99% UV filter. The blacklight and red laser had no effect, but the filtered xenon flash still disrupted the circuit.

So it seems that UV, violet light, and low-intensity IR are not the culprit, but 532nm green light is one of possibly multiple wavelengths causing the issue. High intensity IR could still be one as well.