1
\$\begingroup\$

I am looking to implement some burn-in to exercise the cpu, memory, and flash of our assembly during production.

What is used in the mass production world to burn in these components before any high level software is used?

My current strategy is to write/read on cycle from memory for some time, then perform a hard computation on the cpu (crunch SHA or similar). In a simple ARM utility (run on bare metal)

The architecture is a simple computer, ARM G20 cpu with nand flash, seperate application flash, and sdram. Unfortunately JTAG is unavailable at this time.

\$\endgroup\$

1 Answer 1

3
\$\begingroup\$

No JTAG access? You may regret that one :) It depends how crazy you want to get, for a professional product I will have several steps in manufacturing for catching errors.

For example:

  • Visual inspection coming off the line, automated 5dx x-ray (although I think this is kind of useless).
  • ICT or clamshell test where a test fixture is used to probe and examine all connections, signals, maybe even run some short tests. JTAG is useful here. If I can't afford ICT I might do flying probe, and if I can't afford that just a poor man's version over JTAG.
  • My burn in screen
  • Final functional test

Now burn in, I think the pro way to do it would have been to take your product through HALT (highly accelerated life testing) until it breaks. Then you can use that data to a.) fix your product, but b.) develop a screen that you want to run before FVT (functional test). HALT is a shake and bake operation, but you may decide after reviewing the results that you should run your boards as you describe at 55C for 1hour to weed out any infant mortality. Over time as you gather more data about failures you may increase or change the tests in your screen.

Now you can shortcut that if you want and just say well I need to run a minimum memory test for 5 minutes a board, it's really up to you. But you should ask yourself what are you really testing there, really that's just a pre-functional test it's not stressing your boards any to try to find early failures.

For an example I took over a board that had some field failures that were traced back to poor manufacturing controls. In addition to changes we made after failure analysis, they're now run under a more extreme temperature and power cycling routine while processing a heavy load to shake out any possible issues.

In another example I was running some very high volume consumer products where the time it would take to do ICT was too expensive, so we just had a built in functional and burn in test that they would run when they were powered up on the floor of what was essentially a giant warehouse. Failures were thrown in a pile to be dealt with later...

Coming up with the right screen takes some experience and is product specific. Myself I usually partner with either my FA lab or my HALT test lab to come up with my initial screens, but you can do it on your own too if you have the time / equipment. I've gone so far as to build a test oven out of a truck toolbox when I haven't had the budget for an oven so you can always come up with something :) The only word of warning is you don't want to get too crazy with your tests to the point that they themselves are lowering the life of the board, this is where an experienced quality person comes in handy.

\$\endgroup\$
6
  • \$\begingroup\$ We have HALT (HASS) on the assembled product so the CPU test is initially more functional (assembly validation) to catch functional issues earlier in the chain at pca not at home, it would be very useful for us to have a pca specific HALT before it gets to us with all the value added, so thank you for the elaboration \$\endgroup\$
    – crasic
    Commented Aug 5, 2015 at 0:01
  • \$\begingroup\$ Yes, we are aware of the utility of JTAG just too late for this assy, also the intended running time is in the hours not minutes. \$\endgroup\$
    – crasic
    Commented Aug 5, 2015 at 0:02
  • \$\begingroup\$ I feel like if you want to catch assembly issues then I would definitely put an ict test or at the least flying probe in place. Then you know your connections are solid. Since no jtag maybe you have a spi or i2c port that the pogo pins could touch? If so you can branch out from there for instance running a memory test and checking that all bits toggle by talking to the ict over spi. Just a thought. \$\endgroup\$ Commented Aug 5, 2015 at 0:06
  • \$\begingroup\$ If you just want to run a memory checking, algorithm check and performance test over and over I don't know that it will buy you much if you aren't also stressing the board itself but you can give it a shot and see if anything falls out. \$\endgroup\$ Commented Aug 5, 2015 at 0:07
  • \$\begingroup\$ There are multiple comm options available, most likely rs232, even JTAG via nail bed on some examples. Currently ICT is done with a small jig by hand, but they cannot catch cpu issues (except supplies) \$\endgroup\$
    – crasic
    Commented Aug 5, 2015 at 0:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.