Surface Mount Reliabily Questions - Page 1
Forum section: electronics / projects

author: mribble
author_rank: Regular Contributor
timestamp: October 02, 2011, 01:45:28 pm
content: I have two questions related to issues I'm having with an open source project I'm working on. The project is the next version of the Camera Axe for those interested.www.CameraAxe.comImages:Bad Oscilloscope Image:http://www.glacialwanderer.com/_blog/blog2011/10_Oct/b_bad.jpgGood Oscilloscope Imagehttp://www.glacialwanderer.com/_blog/blog2011/10_Oct/v_good.jpgSchematic:http://www.glacialwanderer.com/_blog/blog2011/10_Oct/ca_schematic.pngPCB Board Layout:http://www.glacialwanderer.com/_blog/blog2011/10_Oct/ca_layout.png1) I have 4 test units and one of them doesn't startup correctly. If it has been sitting for more than 3 seconds I need to turn it on, then turn it off, and then turn it on again. If I just turn it on the micro doesn't initialize correctly. Thinking about this some I realize I probably should have the on/off switch tied to the enable pin on the main boost converter instead of powering up the whole boost converter, but I generally like my on/off switch to be a true on/off so there is no leakage. The two oscilloscope images above are the output voltages from a good unit and the bad unit. All the good units looked like the good graph and I only had one bad unit to test. The bad unit shows the same graph whether turn it turns on correctly or doesn't boot the micro. Comments on this?2) When I mount these boards to the case the operations becomes flaky. I am using metal standoffs that I put on the PCB and then use more screws to put those on the case. If I don't tighten the screws to the case as much the problem isn't as bad. One of the boards I did this with actually failed. I looked into it and it was the SON-10 package on my boost converter (http://www.mouser.com/ProductDetail/Texas-Instruments/TPS61200DRCR/?qs=sGAEpiMZZMtY9G8Xaw%2fcnvufCtuHXcIe). It formed a short between some of the pins on this package. I reflowed the solder with a hot air solderer and the problem went away. My guess is that the problem is causes by board flex? I had this boards assembled by the company who will be assembling the final product so it makes me nervous if just tightening some screws causes reliability issues. Is this a common problem with this package type? Is there things I can do to lessen the issue? Perhaps some kind of flexible washers or some board change?Thanks for any help!

author: amspire
author_rank: Super Contributor
timestamp: October 02, 2011, 02:41:19 pm
content: Just had a quick look.Don't really like the way the reset pin is connected to the FS232's DTR via a capacitor. What happens at start up?I am assuming DTR is normally high, so it is going from low to high at start up at the same time the AVR is starting.Can you put one channel of the oscilloscope on the 5V and the other on the AVR reset pin, and capture a startup?Look for any reset pulses shorter then the specified minimum AVR reset pulse length, or the reset pin going higher then the 5V rail by more then 0.5V. Or lower then the 0v rail by more then -0.5V. 0.6V is too much. Don't know the particular AVR chip you are using, but minumum low pulse on the reset line should be something like 2uSecs or more, so anything shorter may be a problem.If the DTR looks at all ugly, you could remove the capacitor to DTR and see how it goes.Richard

author: mribble
author_rank: Regular Contributor
timestamp: October 02, 2011, 05:15:08 pm
content: Richard, you were correct! Here is the graphs of the 5V bus and the reset pin.http://www.glacialwanderer.com/_blog/blog2011/10_Oct/IMG_2558.jpgWhen the micro fails to start correctly it has the dip in the reset pin. When it works correctly there is no drop and the reset and 5V lines match. I removed that C1 capacitor and it boots fine every time. However, I need that capacitor since it is how the chip is reset so a new program can be loaded onto the micro (using an ATMega368 with the Arduino bootloader). Any ideas how to fix this without removing that capacitor?I'm also still looking for ideas on #2.Thanks!

author: amspire
author_rank: Super Contributor
timestamp: October 02, 2011, 05:37:26 pm
content: You could try adding a 0.01 uF cap from reset to ground, and replace the DTR cap with a diode to allow the DTR to pull Reset low.You may have to add a 100 ohm resistor in series with the diode if discharging the cap is a problem for the 232 chip.Richard.

author: mribble
author_rank: Regular Contributor
timestamp: October 02, 2011, 06:40:53 pm
content: Richard, I don't think the diode will work. DTR gets pulled low while the program is loading so if I put a diode there the mirco will keep getting reset which isn't what I want. I want a single reset when the pin is first pulled low.I did some looking around and it seems like there are a lot of projects that use a cap like I did to reset the micro such as all the arduino boards I looked at. I don't understand why it would be causing me a problem.

author: amspire
author_rank: Super Contributor
timestamp: October 02, 2011, 09:35:13 pm
content: You are right. The Arduino Duemilanove uses the same reset circuit.There is difference, they have the reset pin of the 232 chip connected to 5v. In your schematic, it is floating. Try connecting the 232 reset pin to is 5v pin.Richard

author: mribble
author_rank: Regular Contributor
timestamp: October 02, 2011, 10:18:07 pm
content: Another good point Richard, but that did not help with my problem.

author: amspire
author_rank: Super Contributor
timestamp: October 03, 2011, 12:03:15 am
content: The problem seems to be that the reset pulse is happening at exactly the wrong time for the AVR. A simple fix might be to just increase the 10uF capacitors on the power supply output to say 47uF. This will slow down the power supply startup, and it could eliminate the reset glitch problem. It may also get rid of the power supply overshoot on startup.You could try this by just tacking a 100uF cap across the 5V rail and see if that helps.About the other problem, it is hard to offer advice. The board mounting shouldn't be stressing the board anyway. If it is, why? Even so, it would take bad solder joints for that to affect performance. If it is the fact that you are using metal standoffs and screws, then nylon standoffs and screws are available. When you tighten the screws, are components being pushed against the case walls? If nothing is under stress, there is no way tightening the screws will change anything.Richard

author: mribble
author_rank: Regular Contributor
timestamp: October 03, 2011, 12:36:50 am
content: I think the reset pulse is too short and it confuses the avr. The problem is I don't understand why that reset pulse is happening.I did try the 100uF cap from 5V to GND, but it did not help the problem.

author: amspire
author_rank: Super Contributor
timestamp: October 03, 2011, 04:29:05 am
content: Just had a look and it looks like the Arduino has exactly the same type of waveforms, but they don't have a problem.So I would look more to the Atmega8 fuse settings.Strangely the reset is cleared below the voltage at which the processor might run, so they add a delay from the time the reset gets cleared till the time the processor starts. This delay is something like 6-14 clock cycles, and then a delay of 0, 4ms or 65 ms depending on the state of the SUT0 and SUT1 fuses. you may have it set to 0 delay.Also if the Brown Out Detector is enabled, that only operates well into the processors operating zone, so it ensures the processor never tries to run when the voltage is too low, and it restarts the processor when it is good again.I still don't like the Arduino reset circuit, but it can obviously be made to work with the right settings.By the way, that TPS61200 supply chip looks a brilliant chip. Operation down to 0.5Vin, automatic switchover between boost and buck modes. I think I will have to get some.Richard.

author: amspire
author_rank: Super Contributor
timestamp: October 03, 2011, 05:43:45 am
content: Just looked at an Arduino chip in a programmer, and its fuses were set with SUT0,SUT1 = 0, Bodlevel0 = 0, Bodlevel1, Bodlevel2 = 1 which means brown out threshold =1.8VIn your case, you could change it to BodLevel0, Bodlevel1 = 0, Bodlevel2=1 which would make the threshold 4.3V.Richard

author: mribble
author_rank: Regular Contributor
timestamp: October 03, 2011, 08:42:14 am
content: I can try this, but I was hoping to use the exact same bootloader that Arduino uses. I'm not sure why this wouldn't work since it works for them.

author: amspire
author_rank: Super Contributor
timestamp: October 03, 2011, 11:39:25 am
content: These settings were taken from an Arduino. So your Arduino based processor probably should be similar.The fuse settings are not part of the bootloader code - they are hardware settings rather then software settings, so they operate before the software starts.You should be able to use the Arduino bootloader regardless of the fuse settings. It seems that different AVR chips have different fuses, but all the suggested fuse settings I could find had either BOD enabled, or a startup delay enabled with non-zero SUTx values.Richard

author: mribble
author_rank: Regular Contributor
timestamp: October 04, 2011, 12:38:49 pm
content: First off I'm traveling for work this week so I can't try any more experiments until next weekend.You are completely correct about fuses being separate from the bootloader. I was just grouping these together because the Arduino IDE sets the fuses at the same time as it loads a new bootloader.Anyways, I looked in the datasheet and the minimum reset time is 2 us for the atmega328. The pulse on my graph looks to be 10-20 us so the timing should be fine. That isn't surprising since what must be happening is the ftdi chip must be pulling DTR low, and the 0.1 uF cap was chosen to give a long enough low pulse for reset. Why this problem happens for a significant percentage of my boards and not Arduino boards is still a mystery to me. My best guess is it has something do to the ramp characteristics of my boost converter power chip interacting poorly with the FTDI chip (FT232). It appears that a reset at this low voltage is confusing the 328 micro. I like your approach of trying to ignore that reset command when the micro is at low voltage.The fuse settings I'm using are from arduino setup software:atmega328_isp: HFUSE = DE # 512 byte bootatmega328_isp: LFUSE = FF # Low power xtal (16MHz) 16KCK/14CK+65msatmega328_isp: EFUSE = 05 # 2.7V brownoutSo from this I can seed that SUT = 11 and BODLEVEL0= 101. This means 2.7V brownout and a 65ms startup delay.I'm a little surprised that the 65ms delay on startup doesn't fix my problems since we are certainly in the first 65 ms. Maybe the issue is that even with the startup delay the chip gets confused if we come out of reset right as the brownout threshold is passed (which seems to be the case on the graphs).This weekend I will experiment with setting BOD to 100 (4.3 V). I have my fingers crossed that this will fix the problem.If anyone has other suggestions on this to try let me know.I really appreciate your help Richard. Thanks!

author: amspire
author_rank: Super Contributor
timestamp: October 04, 2011, 01:39:04 pm
content: Now I am really confused.The processor is not starting till way after all the startup issues we have seen.The other thing is all your scope pictures were well before the 65ms point at which the processor starts. I think you have to capture what happens on that reset pin just as the processor starts at 65ms or later. If removing that cap cures the problem, something must be happening.What I am thinking is that at some point after the processor starts, it does something that somehow causes some kind of pulse to come from the 232 chip.In particular, at the point the processor starts the backlight switching IC, a transient is triggered that gets back to the AVR processor vit the DTR from the 232 chip.So trigger of the LCD_BL_ROW pin and view the DTR out and the 5V. Perhaps when the backlight converter starts, it puts the 5V into current limit, dragging it down. You might have to work out the BL converter startup surge, and put an electrolytic cap on the chip big enough to cope with the surge without dragging down the 5V.Does the 232 chip have decoupling capacitors on the 5v right at the chip?Richard.

author: mribble
author_rank: Regular Contributor
timestamp: October 05, 2011, 04:44:00 am
content: I am still suspicious of that initial drop I captured on the scope. One of the parts I have has this issue pretty randomly. Whenever I saw that voltage drop during startup the mirco did not boot properly, but whenever I didn't see that drop it did boot fine.There is a 0.1 uF decompling cap on the 232.I can try and capture more with my scope. I will also try disabling the backlight in software to see if that helps.I've got a few things to try. Nothing seems like a sure fired fix, but at least there are some ideas of things to try.

author: amspire
author_rank: Super Contributor
timestamp: October 05, 2011, 05:24:48 am
content: Given your startup delay, I cant see how anything happening in the first 100uSecs could affect the AVR.That exact waveform was on my working Arduino board - it is just the way the 232 chip works, so it probably happens in just about every Arduino using that chip. A different 232 chips is now used in the current Arduino designs.As I said, I now think the problems is happening after the 65mS mark. It has to be something unique to your particular circuit, and to me that is the backlight converter, and the layout of the board.As a matter of interest, when you say it is not running, how are you determining it is not running. For example could it be running, but the display has no backlight?Richard.

author: mribble
author_rank: Regular Contributor
timestamp: October 08, 2011, 01:23:11 pm
content: I looked for some weird reset happening after the first 65 ms and couldn't find any such signals.I tried setting the brownout voltage fuses to 4.3 V and that did not fix the problem.I tried removing the backlight boost converter chip from the board so the backlight could never use any power and that did not fix the problem.Does anyone have other things I could try?

author: amspire
author_rank: Super Contributor
timestamp: October 08, 2011, 02:42:04 pm
content: This could be a quirky layout problem, a defective chip, a yet to be uncovered software bug - it is hard to guess.You can get information.The power supply overshoots to almost 6V on startup. Try adding enough external capacitance so it does not overshoot and see if it works then. Remember, all the capacitors get charged, and then the supply voltage drops down by 0.8V in about 30uS. Not nice at all.Supply overshot means the supply regulation is underdamped, so it may not behave nice to any load change. See if the supply glitches above or below 5 V after startup.Could it be that the processor is running, but the display has frozen? Have you tried manually resetting the display?Does it run with a USB reset (ie can you program it via USB?)Does it run if after powering up, you manually take the reset low?If it is not running, is the clock running?Are any pins doing anything (to indicate a running program)?Are any pins in a non-default state that would indicate the processor began to run?Next step would be to find out where the processor is freezing.Assuming you are able to program the AVR, add some code to toggle pins. They can be spare pins, or pins already assigned to something else that wont kill anything by toggling. Use the oscilloscope to look for the pins toggling. If the program is starting, keep going till you work out exactly where it is freezing. We know an Arduino board works with the same parts so there is something different happening here. It could easily be a bug in the code, and when a certain combination of events occur, the processor is stuck in an infinite loop. Something like an interrupt triggering at an exact point where the code cannot correctly handle the interrupt.Now also I am no expert on Arduino/Atmel processor fuses. After they are set, if you clear them in the programmer, do they actually clear, or stay set? Could it be that you have ended up with an illegal combination of fuses set?Have Fun!Richard

author: mribble
author_rank: Regular Contributor
timestamp: October 08, 2011, 07:35:02 pm
content: Reseting the processor both via the programmer and manually fixing the issue. Putting int protection diodes for over voltage on reset doesn't help. None of the code on the micro gets run when it is in this bad state (tried having first line set pin high and that never happens).I've also run some experiments and I'm now completely sure that the problem is the issue where the ft232 chip is pulling dtr low during startup (as show in this picture:http://www.glacialwanderer.com/_blog/blog2011/10_Oct/IMG_2558.jpg).I have tried all combinations of the starup delay fuse and the brownout fuse to try and have the atmel chip ignore this, but evidently the atmel chip gets very confused if a reset happens while the chip is being powered up.I have looked at various arduino boards I have here and they don't show this behavior. My guess is that since their power supplies ramp faster the ft232 chip doesn't drop low on them.I see two potential solutions. One is to somehow get the ft232 to stop pulling dtr low during it's startup. Two is to add circuitry to ignore pulse that on the atmel micro.I have a few ideas here, but it seems I'm working around chip quirks. If you have a suggestion for a more robust reset circuit that will handle this let me know.

author: amspire
author_rank: Super Contributor
timestamp: October 08, 2011, 10:37:15 pm
content: Did you try adding extra external capacitance to the 5V rail to get rid of the 5.8V spike on startup?Richard

author: mribble
author_rank: Regular Contributor
timestamp: October 09, 2011, 01:03:44 am
content: Yes. I also tried adding bigger caps by the ft232, and by the battery.

author: amspire
author_rank: Super Contributor
timestamp: October 09, 2011, 01:36:20 am
content: But did the extra capacitance actually get rid of the overshoot on the 5V?

author: mribble
author_rank: Regular Contributor
timestamp: October 09, 2011, 05:25:08 pm
content: It did not get rid of the overshoot. Nothing has completely gotten rid of it, but it is within the 6V spec. I think on a future version I will add a diode to protect against this. I can't remember if it helped reduce the overshoot or not.