Is "integrated circuit burn-in" a thing? - Page 1
Forum section: electronics / projects

author: IDEngineer
author_rank: Super Contributor
timestamp: April 23, 2019, 08:59:53 pm
content: I've got a weird situation going on here.Several of my ongoing projects involve MEMS sensors. I'm qualifying a new (to me) one from ST, the LSM6DS3, which is very popular and very deeply stocked at multiple large distributors so they move a lot of volume. In other words, it's not some obscure part that nobody's heard of.When I powered up the first two proto PCB's with this part, the LSM kept exhibiting these failure modes. It would take anywhere from 30 minutes to 2 hours, but within 2 hours you could pretty much guarantee it would fail. By "fail" I mean the part would change operational modes with no external stimulus. For example, if the part was configured (via SPI) for an update rate of 400Hz, after a while it would switch to (say) 12.5Hz. You could see this on a scope. The even weirder aspect was that reading the configuration registers back out showed the PROPER VALUES for 400Hz (or any other value, I tried several) were still in the registers. And yes, I tried rewriting those proper values back again on the chance that this would cause the chip to re-evaluate them and go back to proper operation - but no luck, the chip stayed in its self-configured mode. The only way to restore proper operation was to invoke its "soft reset" SPI command or power cycle the device.There was another error condition where the SPI interface itself became unresponsive and the ONLY way to regain control of the device was to cycle power. Ugh.I wrote a bunch of failsafe routines to detect and gracefully handle everything but the SPI failure, and over a few days got it to the point where no more failures occurred (at least in the sense that if they did occur, my firmware caught them and dynamically restored proper operation). Then, separately, I discovered that the SPI problem appears to be that the internal digital low pass filters require too much processing power. This led me to suspect that the internal filters are implemented in firmware, not hardware, and when they hit some edge case they take out the internal CPU. By disabling all possible internal filtering and going back to my own filters in my own firmware, the SPI errors also disappeared. At this point two prototypes ran for a couple of weeks with no errors at all.(I'd like to add that every MEMS device I've worked with has weirdnesses like this. They're finicky, and their poor documentation doesn't help. I don't know why they all seem to be like this, but they're simply a PITA to get running. I feel like I could write an aftermarket cheat sheet on the ones I've sleuthed through. However, they're darned useful so I just budget extra time whenever I start working with a new one, knowing I'll be basically writing my own appnote to get them going.)Yesterday, I fired up a fresh proto PCB and left it running overnight. By early this morning, it had entered one of the failure modes! Since my firmware can handle anything but the SPI lockup, all evidence points to the LSM6DS3's internal firmware having locked up again. I didn't have the unit instrumented (I thought we were past this) so I couldn't dig any deeper beyond knowing that my recovery code couldn't handle it, and it handles everything I know about except the SPI failure. Cycling power instantly fixed it, exactly as with the first two units, which further supports the SPI failure theory. Since then it's been running flawlessly for about 8 hours so far today.Thinking about differences between this latest board and the earlier ones, the only one is clock time. They're all running the same firmware, powered by the same supply, flashed by the same programmer, etc. Those first two boards got dozens of hours on them while I was working through the error handling, and their error rate dropped as I discovered more failure modes and wrote firmware to handle them. But maybe those parts were just "burning in" and my code had little to do with it. This latest one had never been out of its antistatic bag before I flashed it and let it run overnight, and within hours it failed such that commanding a reset over SPI would not work (the classic symptom of SPI failure on this part). I've never considered "burn-in" of integrated circuits to be a "thing" before, but this sure feels like it. And these are MEMS devices, which brings in a mechanical aspect that most IC's don't have.Is there anything in the industry about IC burn-in? Perhaps specific to MEMS devices in particular?

author: AndyC_772
author_rank: Super Contributor
timestamp: April 23, 2019, 09:45:40 pm
content: ST's MEMS accelerometers can be very fragile and easily damaged by soldering heat. Were the boards soldered by hand? Have you tried buying a preassembled evaluation board and wiring across to it instead of fitting the bare device to your PCB?

author: IDEngineer
author_rank: Super Contributor
timestamp: April 23, 2019, 10:12:07 pm
content: Thanks for replying!Quote from: AndyC_772 on April 23, 2019, 09:45:40 pmHow would that situation self-correct with time, as appears to be happening here?QuoteNo, they were assembled by a contract manufacturing house that we use all the time. Very high end shop, leading edge pick-and-place and reflow ovens, etc. They do all of our protos and most of our production. I'm confident they followed ST's guidelines from the spec sheet. But again, even if they didn't, anything "damaged by soldering heat" doesn't usually spontaneously repair itself. These parts seem to stop self-reconfiguring after a while, and the two protos that were originally having problems now workperfectly.

author: Whales
author_rank: Super Contributor
timestamp: April 23, 2019, 10:16:59 pm
content: I'd try and contact ST.Even if the parts are very popular, there could be bad batches or other shenanigans.

author: IDEngineer
author_rank: Super Contributor
timestamp: April 23, 2019, 10:42:08 pm
content: Quote from: Whales on April 23, 2019, 10:16:59 pmI did that, first thing (like two weeks ago). ST has stopped having formal trouble tickets and now directs you to their online forums. I have two lengthy threads there, complete with scope screenshots where applicable, but the responses I've gotten have nothing to do with my questions!Example: Here's a paragraph excerpted from one of my messages on the ST forum:Quote...and here's the response:QuoteI talk about disabling filters to improve reliability, and they answer that digital filters have delays. Non-sequitor!Here's what I wrote back, in part:Quote...and there's been no response since. So it appears ST themselves are not going to be a source of useful assistance.

author: SilverSolder
author_rank: Super Contributor
timestamp: April 23, 2019, 11:03:20 pm
content: Any glitches /ground bounce / etc. etc. that could cause the comms or power to be marginal in any way?Is there a demo board available from the manufacturer just to help prove that the chip works at all?

author: IDEngineer
author_rank: Super Contributor
timestamp: April 23, 2019, 11:12:41 pm
content: I worried about noise too, so one of the first things I checked was the signals and supply rails with one of those little homemade "wrap the wire around the probe ground" tricks. Incredibly clean, both signals and power, right at the chip.I don't know if there's a demo board, but remember: The devices that weren't reliable at first are now 100% reliable for days at a time. I don't know how a demo board will affect that.It really is like the chips need to burn in for a while before they get reliable.Update: I just confirmed that the overnight error was due to the SPI failure mode. I have diagnostic LED's on the board that flash in certain patterns so I get a limited amount of debug data when an error occurs. The farther along in the process the code gets, the greater the number of flashes. Crude but effective. I was getting a single flash, which is the MCU telling me that it detected an LSM6DS3 error but, while trying to resuscitate the chip, it is now not getting a valid WHO_AM_I value back from the chip. That's its first test to confirm that the SPI interface is working... and once the SPI fails, there's no recovery except power cycling. (Speaking of power cycling, did you know that there was a MEMS device a while back where cycling power was the RECOMMENDED SOLUTION to an initialization error? I couldn't believe it, but there it was right in the spec sheet. I guess they imagined you'd include a high side PFET and have the MCU selectively cycle power to the device until it initialized properly.)

author: IDEngineer
author_rank: Super Contributor
timestamp: April 23, 2019, 11:39:28 pm
content: More: One of the reasons I selected the ST LSM6DS3 is because it is footprint and pin compatible with the Bosch-Sensortec BMI160. They are not firmware compatible at all, but I've already written the routines for each (and reading back the WHO_AM_I/CHIP_ID values allows me to dynamically discern which chip is installed on a given board). I had the shop build a few units stuffed with the BMI160 too, and so far those have not demonstrated any of these errors. I'm going to start a long-term test on a couple of BMI160 boards to see if anything shows up, but so far this appears to be an ST-specific bug.Why did I worry about second sources? Because on earlier MEMS projects we've run into supply chain problems where a sole-source device went out of stock everywhere with 26 week lead times from the factory. THAT was really fun, so I worked long and hard to find two footprint compatible devices for this project. I can tell ya, there's zero coordination between manufacturers and I was darned lucky to find these two parts to be physically compatible - I can accommodate differences at the SPI/firmware level. (And no, there's no room for a second footprint on the PCB.)

author: SilverSolder
author_rank: Super Contributor
timestamp: April 24, 2019, 01:11:03 am
content: Maybe the high side PFET for surgical power cycling is not such a bad idea? - How much power does the MEMS chip use, maybe it can live off the current from an I/O pin on the MCU, so no PFET is needed?

author: IDEngineer
author_rank: Super Contributor
timestamp: April 24, 2019, 01:49:10 am
content: Quote from: SilverSolder on April 24, 2019, 01:11:03 amI actually did consider that during schematic design when I was using that part a couple of years ago. The MCU runs on 5V0 while all MEMS chips run on something lower... 3V3, 3V0, 2V5, 1V8, etc. So then there'd have to be a regulator in series, which further increases current consumption. As I recall it was still technically possible but I got a little queasy thinking about connecting the input and output caps that regulators need directly to an I/O pin (with the resultant current spikes). Even if I used a regulator that didn't require an input cap, you're still putting the ESR of the I/O pin in series with your supply with who knows what noise effects and transient response (I never actually wired it up). I got deep enough into it that I convinced myself it was a bad idea.Leaving the MEMS supply separate and selectively applying power via a FET that is controlled by the MCU is definitely doable. Given what I'm finding now, I may add that to a future rev of a MEMS board. It just seems so... second-rate. Maybe the best answer is to avoid parts that can only be recovered with power cycling, but as I seem to be learning, they don't always publish that fact in the spec sheet! Some seem honest enough to say so, others are just silent about it.These chips are used in millions of cellphones and tablets. I find it hard to believe they're being power-cycled all the time. The chips have very aggressive power-saving modes that are openly and specifically intended for phones and tablets, to save power. Heck, this LSM6DS3 brags about "Compliant with Android K and L" as the fourth bullet item on the front page of its spec sheet. There's no mystery what market they're targeting. Do I think they added an FET to each cellphone to cycle power on these devices? No, I don't. Their internal power saving modes can drop their consumption to almost nothing... a quick glance shows the LSM goes to 6uA in "power down" mode.One wild, hare-brained theory I have is that the LSM fails if motionless for too long. I've never had one fail while I was actually working on it, only when they've been sitting for extended periods on the bench with nothing happening to it. I might be just a couple feet away cranking on firmware, but there it sits, powered on, sometimes for hours at a time, then I turn to it and voila - dead. And certainly overnight the DUT's aren't moving. Maybe there's some sort of power-saving mode that detects extended periods of motionlessness and seeks to save power, but then doesn't come back out of it. I've researched all the various power modes and done everything I can to switch it into "normal" or "high performance" modes with no power savings at all, but maybe the device's internal firmware has some sort of "we're smarter than you" feature. Hard to test for that, due to the unpredictable timing of these errors.

author: thermistor-guy
author_rank: Frequent Contributor
timestamp: April 24, 2019, 03:34:32 am
content: Quote from: IDEngineer on April 23, 2019, 08:59:53 pmThis part has a moisture sensitivity level of 3, according to Digi-Key:https://www.digikey.com/product-detail/en/stmicroelectronics/LSM6DS3TR/497-15383-1-ND/5180534I would check that your board assembler is receiving these parts in unbroken moisture barrier bags; or if not, that the board assembler is dry-baking these parts before assembly.That's normally the case, but stuff-ups happen.I can remember a case where batches of Xilinx chips were mysteriously failing. It turned out that the supplier was shipping them to our board assembler in unsealed bags. These parts had been sitting on the shelf in a humid warehouse, for months, prior to shipment. The moisture absorbed by the packages caused havoc during automated soldering. Once our Production and Purchasing people got strict about moisture sensitivity safeguards, the problem went away.

author: IDEngineer
author_rank: Super Contributor
timestamp: April 24, 2019, 03:59:57 am
content: Interesting thought on the moisture sensitivity. I wonder if being powered on for a while would bake excess moisture out (for that matter, I wonder if the package is hermetic). If the problem is solely moisture interfering with a good SMT reflow, that is certainly not going to improve with power-on time.I'll confirm with the assembly shop and report back. Thanks!

author: SparkyFX
author_rank: Frequent Contributor
timestamp: April 24, 2019, 05:45:07 am
content: Quote from: IDEngineer on April 23, 2019, 08:59:53 pmThat question reminds me of something: Have the parts been passing an X-Ray while crossing a border or such?There are quite a few things that can damage such sensitive parts.

author: AndyC_772
author_rank: Super Contributor
timestamp: April 24, 2019, 08:01:27 am
content: I know that, with some of these parts, the board layout is critical to avoid asymmetric forces being applied to the device at the point the solder solidifies during reflow. (Might be Freescale rather than ST who specify this).What does your layout look like? Is there anything strongly asymmetrical around the device and the traces immediately leading to it?Maybe there's some residual thermal stress 'baked' into the device after reflow, which reduces over time as the PCB pads are able to move slightly?

author: Whales
author_rank: Super Contributor
timestamp: April 24, 2019, 11:01:52 am
content: Quote from: IDEngineer on April 23, 2019, 10:42:08 pm...Customers not good enough to help directly? Then you're not good enough for customers.My sincere apologies IDEngineer, it sounds like they're fools. That's not a good way of keeping customers.

author: amyk
author_rank: Super Contributor
timestamp: April 24, 2019, 11:35:25 am
content: Quote from: IDEngineer on April 24, 2019, 01:49:10 amI suspect this could be a case of "popular part with little-used feature has a bug" --- it might be worth finding some Android source code from some device that uses this IC to see if it uses the same options (filters, etc.) that you're using.

author: IDEngineer
author_rank: Super Contributor
timestamp: April 24, 2019, 12:46:14 pm
content: Quote from: AndyC_772 on April 24, 2019, 08:01:27 amYou're absolutely correct about mechanical stress affecting such parts, and in the case of the ST LSM6DS3 the spec sheet does explicitly discuss that. But they say, and we've confirmed, that the effect is to impart a bias to measurements in one or more axes. It's interesting to watch the baseline values change as you twist the PCB. I've already written calibration routines into the firmware for exactly this reason. Soldering the parts to the board definitely "locks in" some stress, but twisting the PCB even slightly has a much greater effect. (Note this means the device will need calibration AFTER installation in its final location since mechanical mounting will likely impose some degree of stress on the board.) My calibration routines can be remotely accessed via a software command to make that easier.No, there's nothing inherently asymmetrical about the layout. But it IS an interesting thought that, with time and power applied, the board might warm enough to allow solder migration. However, as I said, the effects stated by ST and seen by us seem to be limited to a measurement bias, not to (firmware?) lockups.

author: IDEngineer
author_rank: Super Contributor
timestamp: April 24, 2019, 12:47:09 pm
content: Quote from: SparkyFX on April 24, 2019, 05:45:07 amI have no way to know what they might have encountered along the way, but neither we nor our assembly house x-rayed them!

author: IDEngineer
author_rank: Super Contributor
timestamp: April 24, 2019, 12:50:44 pm
content: Quote from: Whales on April 24, 2019, 11:01:52 amIn fairness, their technical staff is supposed to be monitoring and responding on the forums. They didn't just abandon technical support, they got rid of the "private trouble ticket" system. I understand the advantages of that, including 1) someone else might answer faster, and 2) the answers become accessible to others with the same question. However, it's the abysmal quality of the "answers" that I'm getting that's so discouraging. As I illustrated above, it's like they don't even comprehend my question. Maybe they just don't believe their part could have such a problem, or that this particular customer is an idiot. The latter may be true, but I guarantee the former is too!

author: IDEngineer
author_rank: Super Contributor
timestamp: April 24, 2019, 12:55:16 pm
content: Quote from: amyk on April 24, 2019, 11:35:25 amThat's just it - this bug isn't in some little-used feature, or even an optional feature like the internal filters. This bug shuts down the SPI interface, theonly way to interact with the device! To be clear, I have managed to eliminate several other bugs by disabling every filter and feature over which you have any sort of control, which I now presume lessens the processing burden on the internal firmware. But this one appears to correct itself with enough power-on time. I suppose I can just insist that Production build a burn-in rack with the appropriate connectors and give them 24? hours, but I'd sure like some sort of confirmation that we're treating the actual disease and not just a symptom.

author: IDEngineer
author_rank: Super Contributor
timestamp: April 24, 2019, 12:57:38 pm
content: It's early this morning, but the result of the overnight test with the BMI160's is that neither of them failed overnight. Like the most recent LSM6DS3 test, that's one board with many hours of power applied and one board literally fresh out of the antistatic bag. When I did this with the LSM's, the new one failed overnight. But now neither of the BMI's show any ill effects. I'll continue letting them run, but it's not looking good for ST....

author: ogden
author_rank: Super Contributor
timestamp: April 24, 2019, 01:09:20 pm
content: Quote from: IDEngineer on April 23, 2019, 10:12:07 pmIt is important that you/they followed spec sheet "Surface mounting guidelines for MEMS sensors", TN1198 (en.CD00134799.pdf)QuoteIt's usually about mechanical stress which may relax after some time or after some number of thermal cycles.

author: IDEngineer
author_rank: Super Contributor
timestamp: April 24, 2019, 03:51:42 pm
content: Quote from: ogden on April 24, 2019, 01:09:20 pmRight, but I would be surprised if mechanical stress could selectively fail the SPI interface. Impose a bias on the MEMS sensor readings, sure. But cause the SPI interface to stop working, after it DID work for 30-120 minutes? Then keep the power applied and "after a while" this error stops occurring and the SPI interface becomes reliable? Hmm....

author: David Hess
author_rank: Super Contributor
timestamp: April 24, 2019, 04:47:53 pm
content: Quote from: IDEngineer on April 23, 2019, 08:59:53 pmBurn-in is a very expensive process so only used on parts which can support the cost. Test time is measured in 10s of cents to dollars per second so it is used as sparingly as possible.Exceptions include high cost parts which support built in self test and grading like microprocessors and memory. The highest precision voltage references may go through extended burn-in. Many military and aerospace qualifications require burn-in.Quote from: SparkyFX on April 24, 2019, 05:45:07 amExposure would have to be 10s of minutes to hours to matter. X-rays roughly act like short wavelength UV exposure except they can penetrate through the packaging. You can use an x-ray generator to erase floating gate memory but as with a UVEPROM eraser, it takes a while.

author: AndyC_772
author_rank: Super Contributor
timestamp: April 24, 2019, 07:44:24 pm
content: Even so, burn-in is normally used to detect early failures, not to somehow magically make faulty parts start working. I'm not aware of any physical mechanism which would cause a damaged part to start working just because it's been switched on for a while.

author: IDEngineer
author_rank: Super Contributor
timestamp: April 24, 2019, 10:38:45 pm
content: Quote from: David Hess on April 24, 2019, 04:47:53 pmI didn't mean burn-in at the foundry. I meant after assembly. Maybe "conditioning" is a better term... basically some period of time with power applied during which "errors" aren't to be considered fatal, while the component conditions or ages or settles or any number of other similar terms. In discrete electronics this wasn't uncommon, you'd allow freshly assembled units to run with power applied for some number of hours before bothering to calibrate them for the first time (again, to be clear, I'm not talking about warm-up after each power application, I mean theinitialapplication of power). This was because many types of components tended to "drift" at first, then settle into a long term stable condition after being powered up for a while. The amount of change quickly went asymptotic after some number of minutes/hours and then could be relied upon to be stable thereafter even after repeated power cycles.I've never heard of that for IC's, but these parts sure act like it and it would explain what I'm seeing.

author: IDEngineer
author_rank: Super Contributor
timestamp: April 24, 2019, 10:40:00 pm
content: Quote from: AndyC_772 on April 24, 2019, 07:44:24 pmI haven't heard of one either, hence this thread.

author: IDEngineer
author_rank: Super Contributor
timestamp: April 24, 2019, 10:41:40 pm
content: Quote from: IDEngineer on April 24, 2019, 03:59:57 amI received their response: Sealed packages from DigiKey in this case, a reputable supplier. And they didn't notice anything unusual when opening the packages nor loading the reels into the pick-and-place machines either.

author: m98
author_rank: Frequent Contributor
timestamp: April 25, 2019, 08:06:50 am
content: I was just about to design an ST accelerometer into a product. Guess I will use an alternative part instead.There is a recovery period for some parts, some hygrometers and gas sensors for example only perform to their specs a week after soldering.

author: SiliconWizard
author_rank: Super Contributor
timestamp: April 25, 2019, 02:07:13 pm
content: Burn-in of active parts for high reliability devices is certainly a thing. It's meant to help getting rid of early failures.In your case, I'd venture there is probably something very wrong that is way beyond the scope of burn-in. Failures in a matter of a couple hours in normal conditions with several devices doesn't look right. So either the batch of ICs you got is all faulty, or your design is? I never saw such a problem with MEMS accelerometers. Admittedly I only ever used AD and TE accelerometers, but ST ones can be found in many mobile devices. You should probably contact ST for support.

author: IDEngineer
author_rank: Super Contributor
timestamp: April 25, 2019, 03:09:53 pm
content: Quote from: SiliconWizard on April 25, 2019, 02:07:13 pmThe evidence is mounting that this is an ST problem. I'm up to ~72 continuous hours on some BMI160's with zero issues (just scoped them again before typing this). That's the exact same PCB, exact same BOM, assembled at the same time as the LSM6DS3 boards, same same same EXCEPT for which part was stuffed in that footprint. As noted earlier in this thread, those two devices happen to share a compatible footprint so we can build boards that are identical in every way except for which device is stuffed into location U7. The LSM demonstrates this weird "burn in" behavior, while the BMI appears not to.QuoteSee my comments about ST support earlier in this thread....

author: IDEngineer
author_rank: Super Contributor
timestamp: April 25, 2019, 03:18:34 pm
content: I've just remembered one "difference" between the two devices: Their "typical" supply voltage.The LSM has supply specs of 1.71V (min), 1.8V (typ), 3.6V (max). The BMI has supply specs of 1.71V (min), 3.0V (typ), and 3.6V (max). We run both parts on a 2V5 rail that was already in this board's previous design. I personally contacted both vendors and asked them if their 1V8/3V0 was actually preferred, or if 2V5 (which is obviously well within both device's specs) had any disadvantages compared to their "typical" supply voltage value. Both companies replied and explicitly said that 2V5 was perfectly fine and that voltage had no disadvantage compared to the "typical" values they listed in their spec sheets.I don't think that could cause this LSM problem, but I did notice it and got the manufacturer's opinion before committing. That said, 2V5 isn't their "typical" value for either part and is 50% higher than the LSM's "typical" while still comfortably within its acceptable range.Just tossing that out there in case it rings a bell for anyone. Again, I can't imagine how a part would stop locking up after it "grew accustomed" to a different supply voltage....

author: IDEngineer
author_rank: Super Contributor
timestamp: April 25, 2019, 03:26:36 pm
content: Quote from: m98 on April 25, 2019, 08:06:50 amThe Bosch-Sensortec BMI160 (compatible footprint, though not firmware compatible) is looking good electrically. However, it appears less tight on its axes-to-package physical alignment. I'm seeing misalignments of 2+ degrees on some BMI160's. Your downstream firmware can compensate for this by doing the appropriate 3D coordinate rotations, but it's something to keep in mind.Some earlier MEMS devices included guaranteed specs for the alignment of their die axes with those of the package. I've noticed that particular spec has disappeared from most spec sheets now. My guess is it reduces production cost for them by not having to individually characterize every device, and they probably assume most installations are doing some sort of in-place calibration anyway so why duplicate that. The downside is that with these earlier devices their alignment was often close enough for many non-critical applications as long as your pick-and-place equipment did a good job, but now it appears you cannot rely on that unless +/-2 degrees of misalignment doesn't matter. Maybe it doesn't for game controllers or something, but in our case it DEFINITELY matters. This had me originally favoring the LSM but given that part's apparent reliability issues the BMI is looking better every day!

author: SilverSolder
author_rank: Super Contributor
timestamp: April 25, 2019, 05:33:16 pm
content: Could it be that you were just unlucky, and if you bought some more parts they would behave better?

author: jmelson
author_rank: Super Contributor
timestamp: April 25, 2019, 07:41:59 pm
content: Quote from: IDEngineer on April 25, 2019, 03:09:53 pmDo ALL ST devices go through this issue? If so, I'd suggest getting a few new units and hand-soldering new parts on your boards and repeat the test.It may be that the stresses of reflow soldering in their process may be exceeding what the chips can handle. If you can hand-solder the ST parts in and they are fine, it has to be something to do with the soldering process (or maybe even the P&P machine is shocking the part when planting it on the PCB.)Jon

author: AndyC_772
author_rank: Super Contributor
timestamp: April 25, 2019, 07:57:21 pm
content: Hand soldering imposes far greater thermal stresses on components than a correct reflow profile.I've wrecked several ST accelerometers this way. IIRC they were the first parts I ever had to learn to reflow using a preheater and hot air station, and once I'd figured out how to minimise the peak temperature they ever experienced, they worked fine.

author: Berni
author_rank: Super Contributor
timestamp: April 25, 2019, 08:32:30 pm
content: That is a very weird problem there.I wouldn't really expect any failure in the MEMS structure to actually kill the SPI communication. I seen weird behavior of some MEMS IMUs due to a floating pin, funny enough the problem on that one only seamed to appear when it was at below freezing temperatures. I suppose some noise or bad decoupling could cause the internal CPU to rarely misstep and crash, or perhaps the timings,levels or rise times on some of its pins are capable of putting its internal logic into a weird meta stable state that eventually gets it to crash.As for explaining the "burn in" period that can possibly be caused by soldering flux that was not properly cleaned from the board. It very slowly absorbs moisture from the air, causing its conductivity to drift and making for seemingly time related behavior. Tho these resistances tend to be so high that it takes a floating pin as mentioned above to detect it. It usually takes a very heavy layer of flux and lots of moisture for it to become conductive enough to mess up an actively driven digital signal (But i seen it happen).We also found that ultrasonic cleaners have the ability to kill MEMS devices and barometers

author: floobydust
author_rank: Super Contributor
timestamp: April 25, 2019, 08:59:59 pm
content: What kind of flux, pcb wash and dry are you doing? That can cause problems with moisture ingress and your "burn-in" is just waiting for things to dry out.The reflow profile has to be decent, not sloppy with too much heat or too long. Excessive PCB flex during handling can also cause shifts.Best to be careful and use scientific method (change only one thing at a time) to troubleshoot your problem.Encountering hassles now is much better than when in production...

author: IDEngineer
author_rank: Super Contributor
timestamp: April 25, 2019, 10:22:45 pm
content: Quote from: SilverSolder on April 25, 2019, 05:33:16 pmMaybe... but how many more before they're "trustworthy"? If I have 50 bad parts now, and 50 more all work great, that's a 50% reliability rate. I wouldn't design with a part that is only 50% reliable.

author: jmelson
author_rank: Super Contributor
timestamp: April 25, 2019, 10:24:19 pm
content: Quote from: AndyC_772 on April 25, 2019, 07:57:21 pmMaybe, maybe not! Yes, what you say is possible. But, if you solder one pin at a time, for just a second or so, the BODY of the part never gets heated more than 10 C above ambient. When reflowing, the whole component is heated to 200C+ above ambient. Maybe this part is really sensitive to that internal temperature.OK, you say you had to use a hot air station, that concentrates the heat on the LEADS, not the component body. That's what I'm talking about. My guess is the OP's contract assembler used ordinary reflow, heating EVERYTHING to 250 C for a minute or more.Jon

author: IDEngineer
author_rank: Super Contributor
timestamp: April 25, 2019, 10:26:19 pm
content: Quote from: floobydust on April 25, 2019, 08:59:59 pmAmen to that! Which is why I'm digging into it now, rather than later.The bottom line for me, so far, is that the ST part demonstrates this burn-in behavior while the Bosch-Sensortec part does not. Literally everything else is the same, they were installed on the same group of panelized-then-separated PCB's, all other components are identical and from the same reels, stuffed and reflowed at the same time, etc. There just aren't that many variables to play with, especially since "the other part" doesn't demonstrate the behavior.It's aggravating.

author: IDEngineer
author_rank: Super Contributor
timestamp: April 25, 2019, 10:29:00 pm
content: Quote from: jmelson on April 25, 2019, 10:24:19 pmThat's exactly correct. However, they are very good at what they do. In literally tens of thousands of units they've done for us over the past 3-4 years I've never had a reflow problem, and never seen a problem like this one. That's why I'm so focused on the part, because it's such an outlier and only ONE part is exhibiting weirdness while its second source does not.

author: amyk
author_rank: Super Contributor
timestamp: April 26, 2019, 12:04:04 am
content: The "typ" values in datasheets are usually chosen to demonstrate the best performance in one of several areas (such as power consumption), but as long as the parameter is within limits it shouldn't matter.I recommend also the "buy several and solder them yourself" test, if you could also get a sample from what your assembler was using then that's even better.This part has breakout boards available and is popular enough to be "Arduino-ised", if there was such a weird problem with it we would've heard many many times from others already.

author: IDEngineer
author_rank: Super Contributor
timestamp: April 26, 2019, 12:48:44 am
content: Quote from: amyk on April 26, 2019, 12:04:04 amThat's what I felt as well. Which is why one of my theories (noted earlier in this thread) is that the part doesn't "sit still" very well. My long term tests have been unusual in the sense that most people don't just power up a MEMS motion sensor and then let it sit motionless for dozens of hours. Also, so far (fingers crossed) the prototypes we've send into the field haven't reported this error... and they don't sit motionless either. I'm thinking of building some sort of motion table and letting a long term test run on that, to test this theory, but not sure I have the time to spare anytime soon.EDIT: All of the protos in the field came from the same, single build as the ones I'm using on the bench. So again, no variables there. Just a different use case, mine can sit motionless for hours at a time while those are in constant motion when powered up. Hence my theory....

author: AndyC_772
author_rank: Super Contributor
timestamp: April 26, 2019, 05:56:22 am
content: Quote from: jmelson on April 25, 2019, 10:24:19 pmEvery surface mount component you can buy is designed, tested and rated for reflow soldering.These parts are tiny (~4x4mm) QFN packages; you're not going to quickly solder the pins one at a time by hand without heat conducting into the bulk of the package.

author: SilverSolder
author_rank: Super Contributor
timestamp: April 26, 2019, 04:12:38 pm
content: If the part is available as an Arduino expansion board, maybe it is something to try? (just to see if a different process makes a difference)

author: amyk
author_rank: Super Contributor
timestamp: April 28, 2019, 02:04:49 am
content: Quote from: IDEngineer on April 26, 2019, 12:48:44 am"doesn't sit still" is an interesting theory, but perhaps more interestingly, what orientation are they mounted in when they're sitting still?

author: IDEngineer
author_rank: Super Contributor
timestamp: April 28, 2019, 02:24:31 am
content: Quote from: amyk on April 28, 2019, 02:04:49 amVarious. They're mounted on a 2x2in PCB. If it's one I'm actively working on I have a little PCB holding jig that allows me to rotate and freeze the board in convenient orientations. Otherwise the boards are plugged into test harnesses, left on the bench, and the PCB's just sit in whatever orientation the harness wiring twist happens to settle into. There's no "normal" orientation, I'd bet no two of them have been in the same orientation when they've locked up. The wiring harness twist and weight is more forceful than the weight of the PCB's so the boards can't force themselves into some sort of repeatable orientation.EDIT: But once the wiring harness "settles" each PCB is basically motionless in that (random) orientation because I'm not touching it and nothing moves the bench.