EEVblog Electronics Community Forum
EEVblog => EEVblog Specific => Topic started by: EEVblog 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 (http://www.cypress.com/file/298076/download)
https://www.youtube.com/watch?v=dDcsTnqVgWc (https://www.youtube.com/watch?v=dDcsTnqVgWc)
MAKE SURE YOU WATCH PART 2:
https://www.youtube.com/watch?v=_D_fi_ck9Vo (https://www.youtube.com/watch?v=_D_fi_ck9Vo)
-
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.
-
there is very little chance of a user actually getting into trouble because of it.
One guy did, the one who originally found it.
-
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.
-
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.
-
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.
-
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?
I bet if you properly/thoroughly investigated the system, you could find at least 10 detectable problems/bugs/issues.
No doubt.
-
So you have to continuously use the WiFi
Nope. I recon it will lock up regardless if you are "using" it.
obtain a rare expensive professional (I'd imagine) powerful flashed camera
Nope, any photoflash camera will do. Modern digital still have them you know.
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.
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.
I'm not convinced this is a serious problem now.
It's not, and I never said it was.
-
Next time if you want to check the status of a network link continuously you could use
ping 8.8.8.8 And it will ping continuously on *unix. On Windows you need to add -t.
To stop press ctrl+c.
-
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.
-
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.
-
Next time if you want to check the status of a network link continuously you could use
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.
-
Analogy:
How would you react, if someone made a Youtube video, which seemed to "attacked" Fluke multimeters ?
I've done one:
https://www.youtube.com/watch?v=-13Q-UsXKQM (https://www.youtube.com/watch?v=-13Q-UsXKQM)
And many others for brands and products I'm big fanboy of.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Next time if you want to check the status of a network link continuously you could use
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:
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.
-
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.
-
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.
-
I think it was interesting follow up. How about laser pointer?
-
Next time if you want to check the status of a network link continuously you could use
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 :-)
-
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?
-
Analogy:
How would you react, if someone made a Youtube video, which seemed to "attacked" Fluke multimeters ?
I've done one:
https://www.youtube.com/watch?v=-13Q-UsXKQM (https://www.youtube.com/watch?v=-13Q-UsXKQM)
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 (http://www.telegraph.co.uk/motoring/top-gear/11140833/Top-Gear-crew-flee-Argentina-under-police-escort.html)
-
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.
-
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.
-
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:
-
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. :)
-
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.
-
Footage reshot in record time, uploading now.
-
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.
-
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:
-
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.
-
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.
-
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.
-
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.
-
https://www.youtube.com/watch?v=_D_fi_ck9Vo (https://www.youtube.com/watch?v=_D_fi_ck9Vo)
-
https://www.youtube.com/watch?v=_D_fi_ck9Vo (https://www.youtube.com/watch?v=_D_fi_ck9Vo)
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.
-
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.
-
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.
-
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!
-
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.
(https://www.eevblog.com/forum/blog/eevblog-901-raspberry-pi-3-photoflash-problem-again/?action=dlattach;attach=241044;image)
-
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.
-
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.
-
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.
-
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
-
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.
-
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!
-
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.
-
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.
-
Could the problem occur due to rapid temperature rise of the flash?
Alexander.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
-
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.