Author Topic: EEVblog #901 - Raspberry Pi 3 Photoflash Problem  (Read 17146 times)

0 Members and 1 Guest are viewing this topic.

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31388
  • Country: au
    • EEVblog
EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« on: July 16, 2016, 09:12:21 am »
The Raspberry Pi 3 has the same Xenon photoflash reset problem as the RPi2 !
There is also a problem with the Broadcom BCM43438 WiFi & Bluetooth chipset!
The internet connection will lockup when exposed to sufficient Xenon flash light.
Datasheet:
http://www.cypress.com/file/298076/download



MAKE SURE YOU WATCH PART 2:
« Last Edit: July 17, 2016, 08:19:42 am by EEVblog »
 

Offline mux

  • Regular Contributor
  • *
  • Posts: 119
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #1 on: July 16, 2016, 09:34:13 am »
Meh, I wouldn't qualify the flash problem as 'really bad' before, or really at all noteworthy now. It's a fun physics lesson for sure, but there is very little chance of a user actually getting into trouble because of it.
 
The following users thanked this post: Kilrah

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31388
  • Country: au
    • EEVblog
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #2 on: July 16, 2016, 09:42:39 am »
there is very little chance of a user actually getting into trouble because of it.

One guy did, the one who originally found it.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31388
  • Country: au
    • EEVblog
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #3 on: July 16, 2016, 09:43:26 am »
Meh, I wouldn't qualify the flash problem as 'really bad' before, or really at all noteworthy now.

It's just as noteworthy now as it was back then.
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2397
  • Country: gb
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #4 on: July 16, 2016, 10:09:27 am »
Meh, I wouldn't qualify the flash problem as 'really bad' before, or really at all noteworthy now.

It's just as noteworthy now as it was back then.

When Intel had the Pentium Divide bug, a very long time ago. Initially Intel wanted to just ignore it and carry on. Eventually they were somewhat forced to address the issue, so there was an expensive recall and it got fixed.

Since the Rasberry PI 3, is an extremely good value for money, educational/simple computer system, they are aiming for the $29.99 market. Many computers are $299.99 or even $999.

They may have decided that the issue is not important enough to fix and/or it will be fixed when the new generation eventually comes out and/or they will eventually fix it in the current model.

I bet if you properly/thoroughly investigated the system, you could find at least 10 detectable problems/bugs/issues.

Looking at the typical return fail modes (on this forum, via the chap selling lots of untested ones), the SD card system seemed to be a common problem area. If I remember correctly the WiFi doesn't work, or is problematic and/or the driver is not ready yet.

tl;dr
It has apparently been designed down to a low/fixed (apparently) price point, and they make little/no profit on them (maybe, I'm not sure). So I'm not at all surprised.

Maybe it is on a todo/fixme list, and is too low priority to get fixed yet ?

For the price, I'm very impressed with the quality of them. They seem really nice and usable. I've not had any problems with them myself. They seem very well built.
« Last Edit: July 16, 2016, 10:13:56 am by MK14 »
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2397
  • Country: gb
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #5 on: July 16, 2016, 10:33:30 am »
I hadn't seen the video, with my previous post. Now I've seen a lot of it.

So you have to continuously use the WiFi, have the unit uncased (some people case them), turn it upside down, obtain a rare expensive professional (I'd imagine) powerful flashed camera, then patiently flash it about ten times, holding the flash an unrealistic 1 cm away from the chip. Then you act like this problem is a complete disaster, on a fun $29.99 computer ?
tl;dr
It seems considerably better than the earlier board (3 vs 2), and seems like a very minor problem, which needs fairly complicated and involved techniques, just to reproduce it.

Anyway they are getting there, and seem to be fixing things, which is good.

The top chip being susceptible is still at least a minor issue I guess. But you have to go so close with the flash now, it does not seem too bad.

As regards the WiFi chip, is someone in real life going to uncase it, turn it upside down, and flash it ten times, from 1 cm away, while aiming for a particular component on the PCB and running WiFi heavy software ?

I'm not convinced this is a serious problem now.
« Last Edit: July 16, 2016, 10:45:44 am by MK14 »
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31388
  • Country: au
    • EEVblog
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #6 on: July 16, 2016, 11:03:10 am »
Since the Rasberry PI 3, is an extremely good value for money, educational/simple computer system, they are aiming for the $29.99 market. Many computers are $299.99 or even $999.
They may have decided that the issue is not important enough to fix and/or it will be fixed when the new generation eventually comes out and/or they will eventually fix it in the current model.

Sure, but that doesn't mean I shouldn't do a video showing that it's still a possibility?

Quote
I bet if you properly/thoroughly investigated the system, you could find at least 10 detectable problems/bugs/issues.

No doubt.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31388
  • Country: au
    • EEVblog
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #7 on: July 16, 2016, 11:06:47 am »
So you have to continuously use the WiFi

Nope. I  recon it will lock up regardless if you are "using" it.

Quote
obtain a rare expensive professional (I'd imagine) powerful flashed camera

Nope, any photoflash camera will do. Modern digital still have them you know.

Quote
Then you act like this problem is a complete disaster, on a fun $29.99 computer ?

What's the problem with me making a video showing that it's still possible?
I don't understand all the people complaining about this (see youtube comments)
I'm not making out it's a big issue, in fact I said the opposite that it's a remote possibility.

Quote
The top chip being susceptible is still at least a minor issue I guess. But you have to go so close with the flash now, it does not seem too bad.

Correct, and I said precisely that in the video.

Quote
I'm not convinced this is a serious problem now.

It's not, and I never said it was.
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 3500
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #8 on: July 16, 2016, 11:23:32 am »
Next time if you want to check the status of a network link continuously you could use
Code: [Select]
ping 8.8.8.8 And it will ping continuously on *unix. On Windows you need to add -t.
To stop press ctrl+c.
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2397
  • Country: gb
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #9 on: July 16, 2016, 11:28:10 am »
Long post, see above for original

Sorry if I've appeared overly critical!

The "real problem", I think is a psychological/human nature one, which I've got (I admit and think it), and maybe the Youtube commentators have the same issues in some cases.
The thing is, the Rasberry PI is "our baby", our/my favorite "toy" (conceptually speaking, of course, it's not anywhere near being my favorite in practice).

Analogy:
How would you react, if someone made a Youtube video, which seemed to "attacked" Fluke multimeters ?
How would Apple Iphone users, react to a Youtube video, criticizing them ?

So I think I have reacted to a combination of the Youtube video title, and criticism of "our baby".

I don't know if what I am saying makes any kind of sense ?

I mostly agree with your comments in principle, and I'm sorry if I've appeared overly critical of "Your baby", that particular video  :-[ :-[ :-[

tl;dr
I over-reacted to just the title, and the fact that my very much liked series of very nicely priced (UK) computers were being apparently criticized, possibly unfairly, causing me to produce the pair of annoying to you (maybe), posts.

tl;dr2
Yes, I think I've been somewhat non-impartial, due to the Raspberry PI's success in the UK, and world wide. With me being very prowd that it was designed and made in the UK.

Disclaimer:
I'm trying to interpret my psychological feelings and motivations. Such analysis can be error prone.

My apologies again. I should have taken much more time and care, before criticizing the thread and video.
« Last Edit: July 16, 2016, 11:38:58 am by MK14 »
 

Offline chris_leyson

  • Super Contributor
  • ***
  • Posts: 1412
  • Country: wales
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #10 on: July 16, 2016, 11:33:24 am »
I think the real engineering issue is whether the RPi resets because of the light getting into photosensitive areas of some chips or the magnetic pulse from a Xenon flash. Try covering the board with something opaque, that will eliminate the light issue. My guess is that it's a magnetic pulse issue.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31388
  • Country: au
    • EEVblog
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #11 on: July 16, 2016, 11:37:21 am »
Next time if you want to check the status of a network link continuously you could use
Code: [Select]
ping 8.8.8.8 And it will ping continuously on *unix. On Windows you need to add -t.
To stop press ctrl+c.

Didn't know that, thanks.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31388
  • Country: au
    • EEVblog
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #12 on: July 16, 2016, 11:39:10 am »
Analogy:
How would you react, if someone made a Youtube video, which seemed to "attacked" Fluke multimeters ?

I've done one:


And many others for brands and products I'm big fanboy of.
 
The following users thanked this post: MK14

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31388
  • Country: au
    • EEVblog
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #13 on: July 16, 2016, 11:42:18 am »
I don't know if what I am saying makes any kind of sense ?

Yes it does, it's the fanboy effect, and Youtubers like me are all too aware of it.
I did not expect it in this case though, hence my surprise, as IIRC I got none of this criticism for my RPi2 video on the exact same thing.
I thought it was obvious from the video that it's essentially a "non-issue" for almost everyone, and was mainly of academic issue. And somewhat humorous if they tried to fix it and potentially didn't fix it entirely.
 

Online Monkeh

  • Super Contributor
  • ***
  • Posts: 6419
  • Country: gb
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #14 on: July 16, 2016, 11:44:46 am »
I think the real engineering issue is whether the RPi resets because of the light getting into photosensitive areas of some chips or the magnetic pulse from a Xenon flash. Try covering the board with something opaque, that will eliminate the light issue. My guess is that it's a magnetic pulse issue.

With the RPi2 it was most definitely light. It's very likely the same issue now, as although they've changed the package, the silicon should still be exposed underneath.
 

Offline chris_leyson

  • Super Contributor
  • ***
  • Posts: 1412
  • Country: wales
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #15 on: July 16, 2016, 12:10:27 pm »
Quote
With the RPi2 it was most definitely light
Undoubtedly it was light on the RPi2 but if you cover the light sensetive area and then try a Xenon flash at the same distance, if it still resets then it's a magnetic coupling problem. di/dt is quite high in a Xenon flash and and it probably deosn't take much flux linkage to induce enough volts into a high impedance track. How is the ground plane arranged, if there is a slot in the ground plane then there will be an induced voltage across the slot for example.
 

Offline Kleinstein

  • Super Contributor
  • ***
  • Posts: 7546
  • Country: de
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #16 on: July 16, 2016, 12:24:20 pm »
If chips are light sensitive, it's more the near IR that causes problems. UV light is easily absorbed and does not come very far in silicon or most plastics. So it could be light to the still exposed sides.  A magnetic coupling is also possible - the flash is quite a powerful source of EMI.

I don't think this is a real issue - you can cover the board if needed, just be aware of the possible trouble.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31388
  • Country: au
    • EEVblog
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #17 on: July 16, 2016, 01:05:21 pm »
I think the real engineering issue is whether the RPi resets because of the light getting into photosensitive areas of some chips or the magnetic pulse from a Xenon flash. Try covering the board with something opaque, that will eliminate the light issue. My guess is that it's a magnetic pulse issue.
With the RPi2 it was most definitely light. It's very likely the same issue now, as although they've changed the package, the silicon should still be exposed underneath.

Yes, almost certainly the same issue now that I didn't even think to actually test it. Layout looks identical to the RPi2
I should probably test the WiFi chip better though, but i couldn't get it to fail when the board was flipped over, no matter how close.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31388
  • Country: au
    • EEVblog
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #18 on: July 16, 2016, 01:47:48 pm »
You've put "AGAIN!" in capitals. My first impression was that you are criticising them for not ensuring the issue was resolved once and for all.

Fair point, that was not my intention, it was meant to be read as as though it's a surprise.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31388
  • Country: au
    • EEVblog
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #19 on: July 16, 2016, 02:34:17 pm »
If anything this seems like a video that didn't need to be made.

I think you have a distinct lack of imagination.
The original RPi2 problem was very well publiciced, and it would be very easy for someone to see that and ask the question "Does that happen on the RPi3 as well or have they fixed it?"
I know, because I asked that exact same question myself, so I did a quick search and couldn't find the answer, so I did a video on it.
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2397
  • Country: gb
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #20 on: July 16, 2016, 02:53:32 pm »
If anything this seems like a video that didn't need to be made.

I think you have a distinct lack of imagination.
The original RPi2 problem was very well publiciced, and it would be very easy for someone to see that and ask the question "Does that happen on the RPi3 as well or have they fixed it?"
I know, because I asked that exact same question myself, so I did a quick search and couldn't find the answer, so I did a video on it.

The video is/was fine, and the concept of revisiting this issue, and examining it is fine.

But I agree (with others), that the title was causing provocation.

Rather than
"EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN"

(I think you already edited the title, partly).

"EEVblog #901 - Raspberry PI 3 Is the Photoflash problem gone now ?"

Or

"EEVblog #901 - Raspberry PI 3 Is the Photoflash problem gone ?"

Then it tempts people to watch it, and does not imply that it hasn't been fixed and/or greatly improved as regards photoflash.
« Last Edit: July 16, 2016, 03:02:17 pm by MK14 »
 

Offline Maalobs

  • Contributor
  • Posts: 16
  • Country: se
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #21 on: July 16, 2016, 03:21:06 pm »
Next time if you want to check the status of a network link continuously you could use
Code: [Select]
ping 8.8.8.8 And it will ping continuously on *unix. On Windows you need to add -t.
To stop press ctrl+c.

Didn't know that, thanks.

I had the same thought when I watched the video, why use a buffering video-stream in an attempt to show interruptions in the network? :D
You don't even need to ping the internet, just ping your office router, and use this commandline:
Code: [Select]
sudo ping -s 8 -A <router ip-address>This will blast your router with pings as fast as possible, and you'll instantly see if there are any interruptions.

As for the butthurt expressed in this thread, the people I know who use the RPi and myself included, do it with the bare boards.
I think it's a very valid question to investigate if the board is susceptible to any form of radiation.
If you're aware of it you can take proper precautions, so of course it should be investigated.
Maybe in Raspberrry Pi 4 someone will make sure that no new bare flipchips are added to the board, thanks to the awareness raised about the issue.
 

Offline SeanB

  • Super Contributor
  • ***
  • Posts: 15391
  • Country: za
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #22 on: July 16, 2016, 03:59:22 pm »
They look to have reduced the effect on the PSU chip by using a back opaque epoxy coat, likely applied during manufacture to the whole die before scribing and then handled like a regular die, just with the thin back coat. Probably should do the same to all the flip chips there, but as they likely only buy in small amounts doing it for the larger chips would not be cost effective, doing a few wafers of a small chip at a cost of a few hundred dollars for the extra step ( and buying this special lot of tested dies all up front) was likely cheap enough, only adding a cent or so to the final BOM cost, and reducing the likely occurrence again by a large amount.

Not really a worry in most cases, you really should have bare dice in a package to protect from moisture in any case, so a simple solution for the few who want a bare board only is to simply get a COB vendor to use the blob of resin dispenser to coat all the chips on the boards, and sell them as developer versions, or a more moisture resistant version after a selective transparent conformal coat of the rest of the board.

This light effect is a nice edge case though, often not though of in design, and a good reminder that to most electronics the world is a hostile place.

Wonder just how much radiation the board will survive while remaining operational, anybody ( Mike, Fraser) care to place one in an Xray scanner for a while while powered and see if they fail as you ramp up the dose. Do not think anybody will want to go into a working or failed nuclear reactor with one as a control, unless there is a lurker working at a Cyclotron with experiment time to spare.
 

Offline G7PSK

  • Super Contributor
  • ***
  • Posts: 3698
  • Country: gb
  • It is hot until proved not.
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #23 on: July 16, 2016, 04:42:47 pm »
What happens if it is exposed to a professional photo flash set up, there is many times more energy from those. Will it kill the chip permanently and from what distance etc. 
 

Offline 6581

  • Supporter
  • ****
  • Posts: 79
  • Country: fi
EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #24 on: July 16, 2016, 05:37:26 pm »
I think it was interesting follow up. How about laser pointer?
 

Offline arekm

  • Supporter
  • ****
  • Posts: 149
  • Country: pl
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #25 on: July 16, 2016, 05:48:14 pm »
Next time if you want to check the status of a network link continuously you could use
Code: [Select]
ping 8.8.8.8 And it will ping continuously on *unix. On Windows you need to add -t.
To stop press ctrl+c.

Better apt-get install mtr
mtr destination
press d (once or twice) - and you will get asci-graphical information :-)
PLD/Linux Team. Electronics as a hobby.
http://readme.maven.pl/
 

Offline BenTheHokie

  • Newbie
  • Posts: 1
  • Country: us
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #26 on: July 16, 2016, 05:57:49 pm »
I'm a bit confused. Doesn't the PE effect only work for UV light that has enough energy to knock off some charge carriers? Why do they say a laser pointer has the same effect? Shouldn't most laser pointers be low frequency red light? I know the semiconductor industry uses UV light for photoresist for etching into the silicon, but that's still UV. Any clues here?
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2397
  • Country: gb
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem AGAIN
« Reply #27 on: July 16, 2016, 08:17:24 pm »
Analogy:
How would you react, if someone made a Youtube video, which seemed to "attacked" Fluke multimeters ?

I've done one:


And many others for brands and products I'm big fanboy of.

Thanks!   Very relevant as well.
I really enjoyed that video, it was apparently very accurate, and would seem to represent a problem (with some Flukes), which we need to know about etc.

I'm also a Fluke fanboy, but accept that because it is used as a measuring device, and it could even be dangerous if the readings were unexpectedly wrong. E.g. A high voltage wire, reads as a safe low voltage, etc etc.

Sorry if I appeared overly critical or harsh, before.
I think it boiled down to a title, which (although may have seemed innocent/safe enough to yourself and some others), could bring on bad feelings to some people.

Even when experts in the industry produce, quality many tens of millions of viewers TV and films, sometimes they relatively unexpectedly get lots of complaints from some people in society.
E.g. They use a word a lot, which they did not realize means something very rude, in some foreign countries, and some people there get very annoyed. Potentially eventually leading to some action or compromise being needed.

Something like that happened on a popular UK TV programme called "Top Gear", where in one episode filmed in Argentina, they used (reportedly an innocent mistake with no intent, but some conspiracy theories say otherwise ...) a number plate, which if you stretch the imagination, when you look at the vaguely random letters and numbers, pokes fun at the Argentinians, over the British Falklands war win, some time ago.
It got so bad the entire "Top Gear" team, of many tens of people, had to leave what was essentially a dangerous mini riot situation, very rapidly in their vehicles.

http://www.telegraph.co.uk/motoring/top-gear/11140833/Top-Gear-crew-flee-Argentina-under-police-escort.html
 

Offline Someone

  • Super Contributor
  • ***
  • Posts: 2467
  • Country: au
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #28 on: July 16, 2016, 11:24:49 pm »
I'm a bit confused. Doesn't the PE effect only work for UV light that has enough energy to knock off some charge carriers? Why do they say a laser pointer has the same effect? Shouldn't most laser pointers be low frequency red light? I know the semiconductor industry uses UV light for photoresist for etching into the silicon, but that's still UV. Any clues here?
The UV light cannot penetrate very deeply into silicon, so while it has more energy the red light is getting further into the silicon which could be causing problems.
 

Offline linux-works

  • Super Contributor
  • ***
  • Posts: 1945
  • Country: us
    • netstuff
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #29 on: July 16, 2016, 11:53:39 pm »
same problem on intel's arduino 101 (curie) board.  there is a chip that is exposed and is light sensitive like this.

if you do a video, try to get an ard 101 board and show that, too.  its more systems than you might think - that use bare chips like that.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31388
  • Country: au
    • EEVblog
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #30 on: July 16, 2016, 11:55:20 pm »
Just shot a follow-up video to this and lost ALL the footage because of that stupid SD card bug in the Canon HF G30  :rant:
 

Offline Muttley Snickers

  • Supporter
  • ****
  • Posts: 2117
  • Country: au
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #31 on: July 17, 2016, 12:24:58 am »
At the risk of repeating myself, the big guns at Canon should be taken out the back and shot.   :rant:

Any chance you could do a similar test with an alarm strobe light in close proximity ?, some of the newer ones are using LED's but the earlier ones used Xenons, very flashy indeed.   :)
 

Online Monkeh

  • Super Contributor
  • ***
  • Posts: 6419
  • Country: gb
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #32 on: July 17, 2016, 12:25:41 am »
Just shot a follow-up video to this and lost ALL the footage because of that stupid SD card bug in the Canon HF G30  :rant:

Surely it's time that thing got widlarized.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31388
  • Country: au
    • EEVblog
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #33 on: July 17, 2016, 12:33:18 am »
Footage reshot in record time, uploading now.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31388
  • Country: au
    • EEVblog
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #34 on: July 17, 2016, 12:34:05 am »
At the risk of repeating myself, the big guns at Canon should be taken out the back and shot.   :rant:

The exact same bug is possible on my Sony NEX-VG30, it ain't just Canon.
 

Offline Muttley Snickers

  • Supporter
  • ****
  • Posts: 2117
  • Country: au
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #35 on: July 17, 2016, 12:52:37 am »
At the risk of repeating myself, the big guns at Canon should be taken out the back and shot.   :rant:

The exact same bug is possible on my Sony NEX-VG30, it ain't just Canon.

Fair enough, I didn't know that and would probably just reload for another shot, or a barrage even.   :rant: :rant:
 

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6004
  • Country: us
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #36 on: July 17, 2016, 01:23:04 am »
I should probably test the WiFi chip better though, but i couldn't get it to fail when the board was flipped over, no matter how close.

You could get the flash closer by removing the camera lens.

Anyway, interesting video regardless of how significant the problem is.
« Last Edit: July 17, 2016, 01:27:51 am by zapta »
Drain the swamp.
 

Online Brumby

  • Supporter
  • ****
  • Posts: 10053
  • Country: au
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #37 on: July 17, 2016, 02:54:56 am »
What happens if it is exposed to a professional photo flash set up, there is many times more energy from those. Will it kill the chip permanently and from what distance etc.

This is a similar direction to where my thinking went.  Electronic flash units vary widely in power output - and the small ones embedded in cameras are nowhere near as powerful as they go.

Then there are the electromagnetic effects.


One wonders if we are travelling down a road that leads to EMP questions.
 

Offline SeanB

  • Super Contributor
  • ***
  • Posts: 15391
  • Country: za
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #38 on: July 17, 2016, 06:19:20 am »
Having watched the follow up video my guess as to what is happening is that the light is flipping configuration bits or register bits in the chipset. Those chipsets have a good number of registers to set up in initialisation ( generally 100 or so, you have to put in the manufacturers magic number set into them, as the actual register architecture is normally not given in the datasheet other than as a "place these values in these locations and she will work, no worries mate" block) to make it run to your standard and power level. Flipping a bit that is internally used to set a critical path or information will cause it to stop responding, or will change an internal mode to something else or even turn off the one side. All have the same external result of no data, and many of them also will not cause the chip to generate any error codes which DMSG will be looking for, as as far as the chip is concerned this is a valid state and not an error, the state matches the setup configuration bits so all is right.

With a laser pointer with a fine beam ( so not the cheap ones off the dollar store) and some precise location you could map out most of the register locations that are critical from the back of the die, though of course just toasting it to unsolder and looking at the front will also tell you, but the back probing is what is used on working dies to reverse engineer them or test for errors in the mask set.
 

Offline mux

  • Regular Contributor
  • *
  • Posts: 119
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #39 on: July 17, 2016, 07:47:31 am »
Nah, I really don't think so. You need a *lot* of charge to flip bits, especially in SRAM. You're talking wells of 10k+ electrons, you're not going to easily get that to work. It's possible (that is how cameras work), but relatively hard.

It's much, much easier to just bias a couple of MOSFETs. You only need a few tens of electrons to jump for that to happen.

Also, memory is generally under a couple of metallization layers, while logic can exist right at the top of the chip, under the first metallization layer.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31388
  • Country: au
    • EEVblog
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #40 on: July 17, 2016, 08:20:42 am »
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2397
  • Country: gb
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #41 on: July 17, 2016, 09:17:46 am »


Thanks,  :-+ :-+

I enjoyed that video.
Also I've been fine with its title as well.

I usually case any Raspberry PIs, that I use, so I should not have these possible problems. Most cases still leave the electrical connectors still available, so you can still do your electronics project with it, if you want.

There is one thing that confuses me though.
If you have a phototransistor, it would be sensitive, to even normal room levels of light. So how come we need such extremely large light levels (i.e. a Camera Flash at close range), to cause an effect ?

All I can think of easily, is that there may be a degree of light absorbing materials (opaque), even with the "bare die" Wi Fi chip and/or it needs to be a very special (rare) light frequency to have an effect. (Or maybe it's "upside down").

EPROMS seem to have a die with a big transparent window on it. So maybe dies are much less sensitive to many light frequencies, than I'm expecting. Maybe it is just some frequencies of UV light, which are problematic ?
There is UVA, UVB and UVC, for the different UV frequency bands.
« Last Edit: July 17, 2016, 09:36:10 am by MK14 »
 

Offline amateur_25

  • Regular Contributor
  • *
  • Posts: 106
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #42 on: July 17, 2016, 11:04:32 am »
What I find weird is ithat I have a version of raspberry pi 2, that doesn't seem to have a U16 on it.

The layout of the power supply area is also completely different.

I can't test for the issue since I don't have an slr with a xeon flash.

You will note that the board from the original video dave did it said Raspberry pi B+ 1.1

However mine is a 1.2 BUT the new video is clearly for version 3.

It would appear the made in the uk version doesn't have a u16 on it as the one in the original video was made in P R C

Not that it matters as Dave has rightly said. Just happened to notice it.

« Last Edit: July 17, 2016, 11:13:32 am by amateur_25 »
 

Offline SeanB

  • Super Contributor
  • ***
  • Posts: 15391
  • Country: za
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #43 on: July 17, 2016, 11:10:39 am »
Mk14,  Simple, the phototransistor has the junctions exposed deliberately, with only a clear oxide layer over them. The IC has the junctions buried deep in the silicon, and you are putting the light through a thick layer of absorbent silicon, which is somewhat transparent to light in the IR while it is opaque to most visible light.

The EPROM also deliberately exposes the floating gates, which is the charge store for the memory, so you can erase it by providing enough UV light to cause the electrons to tunnel through the thin oxide layer erasing the cell.  Slightly different in that they use a floating polysilicon gate electrode in an insulating oxide layer as a gate to control a MOSFET switch, with another gate very close to it that is used only during programming to place a charge in the gate by quantum tunnelling.
 
The following users thanked this post: MK14

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2397
  • Country: gb
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #44 on: July 17, 2016, 11:22:39 am »
Mk14,  Simple, the phototransistor has the junctions exposed deliberately, with only a clear oxide layer over them. The IC has the junctions buried deep in the silicon, and you are putting the light through a thick layer of absorbent silicon, which is somewhat transparent to light in the IR while it is opaque to most visible light.

The EPROM also deliberately exposes the floating gates, which is the charge store for the memory, so you can erase it by providing enough UV light to cause the electrons to tunnel through the thin oxide layer erasing the cell.  Slightly different in that they use a floating polysilicon gate electrode in an insulating oxide layer as a gate to control a MOSFET switch, with another gate very close to it that is used only during programming to place a charge in the gate by quantum tunnelling.
Thanks, I'm very impressed with you answer, which has taught me a lot.

I see, so because only certain parts of the EPROM are actually exposed, which can be carefully/precisely controlled by the masks (or similar) and IC production processes etc. Although to the human eye it appears the chip is "fully" exposed. In reality it is not. Only the parts which need to be erased.
For serious/reliable EPROM usage, it was needed to cover the UV window, ideally with proper UV/EPROM stickers (pricey, because they had an aluminium/metal film), or the cheaper solution was to just use paper labels. Otherwise they would sometimes mis-operate under bright light or even normal light, or maybe even eventually self erase.

Now I understand a lot better, why it is so difficult to get this problem to occur. Thanks again!


« Last Edit: July 17, 2016, 11:24:48 am by MK14 »
 

Online wraper

  • Supporter
  • ****
  • Posts: 11548
  • Country: lv
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #45 on: July 17, 2016, 11:35:18 am »
This is not raspberry pi 2  :palm:, it is what it says on the board - Raspberry pi B+. The same CPU as in original raspberry pi, and has 512 MB ram soldered on top of the CPU/SoC. Raspberry pi 2 has RAM on the bottom of the board.
What I find weird is ithat I have a version of raspberry pi 2, that doesn't seem to have a U16 on it.

The layout of the power supply area is also completely different.

I can't test for the issue since I don't have an slr with a xeon flash.

You will note that the board from the original video dave did it said Raspberry pi B+ 1.1

However mine is a 1.2 BUT the new video is clearly for version 3.

 

Offline SimonR

  • Regular Contributor
  • *
  • Posts: 121
  • Country: gb
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #46 on: July 17, 2016, 12:08:46 pm »
Mk14,  Simple, the phototransistor has the junctions exposed deliberately, with only a clear oxide layer over them. The IC has the junctions buried deep in the silicon, and you are putting the light through a thick layer of absorbent silicon, which is somewhat transparent to light in the IR while it is opaque to most visible light.

The EPROM also deliberately exposes the floating gates, which is the charge store for the memory, so you can erase it by providing enough UV light to cause the electrons to tunnel through the thin oxide layer erasing the cell.  Slightly different in that they use a floating polysilicon gate electrode in an insulating oxide layer as a gate to control a MOSFET switch, with another gate very close to it that is used only during programming to place a charge in the gate by quantum tunnelling.
Thanks, I'm very impressed with you answer, which has taught me a lot.

I see, so because only certain parts of the EPROM are actually exposed, which can be carefully/precisely controlled by the masks (or similar) and IC production processes etc. Although to the human eye it appears the chip is "fully" exposed. In reality it is not. Only the parts which need to be erased.
For serious/reliable EPROM usage, it was needed to cover the UV window, ideally with proper UV/EPROM stickers (pricey, because they had an aluminium/metal film), or the cheaper solution was to just use paper labels. Otherwise they would sometimes mis-operate under bright light or even normal light, or maybe even eventually self erase.

Now I understand a lot better, why it is so difficult to get this problem to occur. Thanks again!

I fell foul of this once, I think it was a 27C011 that wouldn't program in a bright sun lit room, but would in an artificially lit room.
It turned out out that the same die was used for both the 27C010 (might have been the 27C101 it was a long time ago) and the 27C011.
One was 16bits wide and the other was 8 bits wide and a non erasable fuse was programmed at the factory to determin which part it was eventually going to be. In sunlight the state of this fuse would flip and it became the other part until the light was removed. Our customer blamed us for having a faultly programming algorithm but sticking a label on it solved the problem. We informed the manufacturer who fixed the issue in a later die revision.

 
The following users thanked this post: Kilrah

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2397
  • Country: gb
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #47 on: July 17, 2016, 12:22:38 pm »
I fell foul of this once, I think it was a 27C011 that wouldn't program in a bright sun lit room, but would in an artificially lit room.
It turned out out that the same die was used for both the 27C010 (might have been the 27C101 it was a long time ago) and the 27C011.
One was 16bits wide and the other was 8 bits wide and a non erasable fuse was programmed at the factory to determin which part it was eventually going to be. In sunlight the state of this fuse would flip and it became the other part until the light was removed. Our customer blamed us for having a faultly programming algorithm but sticking a label on it solved the problem. We informed the manufacturer who fixed the issue in a later die revision.

That's an interesting story.
The manufacturer should have got their device controlling "fuse" right the first time, and it should have been obvious to consider light traveling through the UV quartz window, as part of the testing and product qualification. But maybe it was too quick a change, as someone internally changed their mind, or wanted to save money somewhere.
It's also possible that their datasheet recommended covering the UV window, when not being erased (speculation) and/or that the device was expected to be cased.

I think people program their chips, typically before covering the UV window, anyway. So it was a bad problem.
 

Offline SimonR

  • Regular Contributor
  • *
  • Posts: 121
  • Country: gb
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #48 on: July 17, 2016, 01:13:19 pm »
Quote
I think people program their chips, typically before covering the UV window, anyway. So it was a bad problem.

I think you're right. In fact you had to program before labeling as you might get fails and you don't want to label a failed part as good. I don't rember if specifically said use a label when programming, I suspect not. It did however say that the the programming algorithm was only qualified between 20 and 25 C. So if you program an EPROM outside of that temparature range they couldn't guarantee the life time of the data.

 
The following users thanked this post: MK14

Offline SeanB

  • Super Contributor
  • ***
  • Posts: 15391
  • Country: za
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #49 on: July 17, 2016, 02:59:47 pm »
True about the programming, but if you read the full datasheets ( not that you get them easily, often you only get the shortform sheet) they do mention the programming being done at between 4V8 and 5V2, with a program and verify of 1ms pulses till it flips, then a longer ( 5 times the pulse total or 50ms whichever is shorter) program pulse to ensure it is programmed. A verify also needs to be done on the fully programmed chip, 3 stages, the first at 4.8V to 5V2, then the second stage to be done at 4V5 ( on some 4V25) and then a final verify at 5V5 ( some manufacturers recommended 6V0 instead) so that you could be sure the data, both zero and one, were readable over the rated operating voltage range, and also by extension the operating temperature range, as the sense amplifiers were tested at both upper and lower threshold levels properly.

Most programmers only implemented the first method of programming, and omitted the variable level verify stage as this was extra complexity in design. Of course the original 50ms per bit program pulse was always allowed and almost always would ensure a perfect program of the chip, the only drawback being the long time it took to program the chip, as you could only do around 18 bytes per second, so a 1Mbit chip would take over 2 hours to program the 128kbytes inside it
 
The following users thanked this post: MK14, SimonR

Offline SimonR

  • Regular Contributor
  • *
  • Posts: 121
  • Country: gb
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #50 on: July 17, 2016, 10:24:38 pm »
Hi SeanB

You're pretty much spot on with that explanation. I used to work for a programmer manufacturer and there were literally hundreds of variations of that algorithm across the many manufacturers. They were mostly just twists on the same theme as everyone patented their own particular version. The ultimate one was called Intel quick pulse. 12 VPP, 6V VCC 10uS pulses up to 25 pulses. I'm not sure if this one had an over prograrm. pulse or not. some needed an extra pulse of number of short pulses required time some other pulse length. My brain is hurting trying to remember it all.

 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31388
  • Country: au
    • EEVblog
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #51 on: July 17, 2016, 11:32:52 pm »
You're pretty much spot on with that explanation. I used to work for a programmer manufacturer and there were literally hundreds of variations of that algorithm across the many manufacturers.

As someone who wrote and sold EPROM programmer software 20+ years ago I can testify to that!
 

Offline Tek_TDS220

  • Regular Contributor
  • *
  • Posts: 66
  • Country: 00
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #52 on: July 18, 2016, 02:50:00 pm »
I'm sure the cause is UV light, but keep in mind that the black tape is probably filled with carbon black.  Can black tape block the electrical pulse from the flash electronics, even though the conductivity of the tape is not high?  I would have used a piece of PET (which absorbs UV) cut from a water bottle, or even a piece of 'soft' glass.
« Last Edit: July 18, 2016, 02:58:23 pm by Tek_TDS220 »
 

Online Monkeh

  • Super Contributor
  • ***
  • Posts: 6419
  • Country: gb
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #53 on: July 18, 2016, 02:57:03 pm »
I'm sure the cause is UV light, but keep in mind that the black tape is probably filled with carbon black.  Can black tape block the electrical pulse from the flash electronics, even though the conductivity of the tape is not high?

Err, carbon black in insulating tape meant to have a breakdown voltage of 40kV/mm? This seems unlikely.
 
The following users thanked this post: Kilrah

Online firewalker

  • Super Contributor
  • ***
  • Posts: 2368
  • Country: gr
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #54 on: July 18, 2016, 05:27:27 pm »
Could the problem occur due to rapid temperature rise of the flash?

Alexander.
Become a realist, stay a dreamer.

 

Offline sibeen

  • Regular Contributor
  • *
  • Posts: 240
  • Country: au
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #55 on: July 24, 2016, 10:26:27 am »
I must be old. I remember having to black texta all over OC81 transistors (if memory serves) to ensure that they weren't acting as inadvertent photo transistors.

This *may* have been a few years ago.
 

Offline mikerj

  • Super Contributor
  • ***
  • Posts: 2461
  • Country: gb
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #56 on: July 24, 2016, 12:57:23 pm »
Why are people attempting to come up with alternative theories?  Flip chip devices are well known to be more sensitive to light, and Dave has done plenty enough to confirm this is the cause in this case.
 

Offline SNGLinks

  • Regular Contributor
  • *
  • Posts: 134
  • Country: gb
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #57 on: July 24, 2016, 10:03:45 pm »
I must be old. I remember having to black texta all over OC81 transistors (if memory serves) to ensure that they weren't acting as inadvertent photo transistors.

This *may* have been a few years ago.
I remember scraping the paint off an OC71 to make an OCP71.
 

Offline eugenenine

  • Frequent Contributor
  • **
  • Posts: 825
  • Country: us
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #58 on: July 24, 2016, 11:11:51 pm »
So what if it has a minor known issue.  Known issues are easier to workaround.  I'll take $29.99 with a known issue over a $500-$1500 system with a close source OS that has random unpublished issues.
 

Offline MK14

  • Super Contributor
  • ***
  • Posts: 2397
  • Country: gb
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #59 on: July 24, 2016, 11:21:18 pm »
So what if it has a minor known issue.  Known issues are easier to workaround.  I'll take $29.99 with a known issue over a $500-$1500 system with a close source OS that has random unpublished issues.

There was a time, when we would often get 3 or 4 blue screens of death, per day. I think (famously) Bill Gates himself was doing a demonstration in front of lots of people. Then suddenly got the blue screen of death. It was/is hilarious.

I think with a number of embedded micros, e.g. Pic. There is potentially a list of erratas anyway. I.e. the MCU can be slightly faulty, even before you design it into a system or computer.
« Last Edit: July 24, 2016, 11:22:49 pm by MK14 »
 

Offline eugenenine

  • Frequent Contributor
  • **
  • Posts: 825
  • Country: us
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #60 on: July 25, 2016, 12:19:13 am »
My work provided laptop did a BSOD last weekend, its a 6 month old laptop and cost $1200.  Back when I worked for a reseller we had one customer with an $Apple$ costing $2000 and he must have sent that thing back to Apple 6 times in the first year.  I upgraded my web server from an RP2 to an RP3 when the 3's were first available, the 2 ran for over a year, maybe once or twice I rebooted when a kernel update was released but no problems.
 

Offline EEVblog

  • Administrator
  • *****
  • Posts: 31388
  • Country: au
    • EEVblog
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #61 on: July 25, 2016, 12:40:48 am »
Why are people attempting to come up with alternative theories?  Flip chip devices are well known to be more sensitive to light, and Dave has done plenty enough to confirm this is the cause in this case.

Yes, it's obviously the light, do the experiment yourself. This is a well known problem with bare die, no mystery at all.
 

Online Monkeh

  • Super Contributor
  • ***
  • Posts: 6419
  • Country: gb
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #62 on: July 25, 2016, 12:49:31 am »
My work provided laptop did a BSOD last weekend, its a 6 month old laptop and cost $1200.  Back when I worked for a reseller we had one customer with an $Apple$ costing $2000 and he must have sent that thing back to Apple 6 times in the first year.  I upgraded my web server from an RP2 to an RP3 when the 3's were first available, the 2 ran for over a year, maybe once or twice I rebooted when a kernel update was released but no problems.

Comparing a high performance laptop running unknown userspace applications on an extremely large and complex codebase with an unstressed webserver.

Apples and peanuts.
 

Online Brumby

  • Supporter
  • ****
  • Posts: 10053
  • Country: au
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #63 on: July 25, 2016, 06:01:38 am »
So what if it has a minor known issue.  Known issues are easier to workaround.  I'll take $29.99 with a known issue over a $500-$1500 system with a close source OS that has random unpublished issues.

You pragmatist, you.   :D
 

Offline Fungus

  • Super Contributor
  • ***
  • Posts: 10826
  • Country: 00
Re: EEVblog #901 - Raspberry Pi 3 Photoflash Problem
« Reply #64 on: July 25, 2016, 06:15:42 am »
So what if it has a minor known issue.  Known issues are easier to workaround.  I'll take $29.99 with a known issue over a $500-$1500 system with a close source OS that has random unpublished issues.

Is it really an issue?

It's really just an experiment to confirm a known theory.

An issue would be if Pis randomly crashed if you took them outdoors at noon or something like that.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf