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

0 Members and 1 Guest are viewing this topic.

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.
 

Offline 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


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf