Power-up tests - opinions? - Page 1
Forum section: electronics / general

author: peter-h
author_rank: Super Contributor
timestamp: August 09, 2021, 06:25:49 am
content: On any new target I have always spent time writing code to test as much hardware as possible.Obviously with off-CPU hardware this is desirable, but what about on-chip stuff like RAM, FLASH, etc?Now running a 32F417 and wondering if there is any point in doing a RAM test, for example.

author: capt bullshot
author_rank: Super Contributor
timestamp: August 09, 2021, 06:46:59 am
content: Checking the FLASH (CRC over used program space) might be useful to prevent the system starting with corrupted firmware.Testing RAM / Flash etc. at boot up time and also during run time is required for functional safety related stuff. For a non-critical system it's up to you to judge if it's necessary. From my experience, it's not.Jack Gannsle (http://www.ganssle.com/tem-back.htm) had some interesting thoughts about self testing in his newsletter.

author: Berni
author_rank: Super Contributor
timestamp: August 09, 2021, 07:34:00 am
content: The MCU itself already comes tested from the factory. They know that some chips come off the line with defects so they do get tested already at the wafer stage. So the chance of getting a MCU with dead RAM cells is very very low. While if you manage to fry a MCU from the outside the result tends to be that its completely dead and does nothing, rather than just some small part being damaged.Self test code mostly looks for bad board connections or dead chips, since this is what will typically go wrong with board assembly.You can still test it if it makes you sleep easier. It is fairly straight forward to do, tho a flash test might take a while due to the slow write speeds and large amount of it on some MCUs. Typically just checksuming your firmware is good enough for that, and its much faster because its only reading flash.

author: Kleinstein
author_rank: Super Contributor
timestamp: August 09, 2021, 08:12:54 am
content: There is usually no need to test flash / EEPROM writes. A RAM test can still make sense as the test on production is only a short one and the conditions (supply / clock / temperature ) can effect the reliability. A failure in the in RAM test may be due to a course different from a dead RAM cell - more like a cell sensitive to poor supply (e.g. decoupling failing) or clock. It can still make sense to catch unreliable operation.In this sense it may even make sense to test the ADC, even if not used in the final application.

author: DavidAlfa
author_rank: Super Contributor
timestamp: August 09, 2021, 09:09:46 am
content: Having a hardware CRC makes it really easy. I can process 64KB blocks at once, you it'll only need a few runs to checkum the whole thing.

author: peter-h
author_rank: Super Contributor
timestamp: August 09, 2021, 01:05:50 pm
content: Some of the code I posted herehttps://www.eevblog.com/forum/microcontrollers/32f417-best-way-to-program-the-flash-from-ram-based-code/msg3623416/#msg3623416is relevant.I realise chips are tested at the factory but I wonder about FLASH. In the days of EPROMs one used to get a (very small) number of duff devices.

author: Kleinstein
author_rank: Super Contributor
timestamp: August 09, 2021, 01:39:22 pm
content: For some devices the factory test includes flashing a test program to do many of the factory tests. So the very basic functionallity is likely tested. For the start up test it is not really practical to test if the flash can actually be written and there is no need to. The program is usually unaltered for most of the product life.

author: Berni
author_rank: Super Contributor
timestamp: August 09, 2021, 04:02:32 pm
content: Quote from: peter-h on August 09, 2021, 01:05:50 pmThere are always possibilities of a fault slipping trough if its marginal enough. But even if it does, the modern MCUs have ECC codes in flash memory so even if a bit does happen to go bad the MCU will continue running like nothing ever happened. If you are this concerned about your memory you might as well also encase your device in a few centimeters of lead in case it gets near a radiation source or gets passed trough a baggage/parcel xray scanner.No matter how careful you are with testing your MCU and product and everything, once you make them in 10s of thousands volumes something will happen. There are perhaps 1000 solder joints in a product, once you make 10 000 units that's a total of 10 milion solder joints. It only takes a one in a million solder joints to fail to make 10 of your devices stop working. How do you make sure each one of those 10 milion joints is perfect? It might be a bad joint that is holding on in testing, but then during vibrations in shipping to the costumer that joint breaks and the product stops working. It is simply impossible to reduce the chance of failiure to exactly 0, you can just take steps to get closer to it. After some point the steps get harder and harder. For example hardware going into space is usually built in many multiples and then put trough very tough testing of all sorts, such as days of vibration exposure, thermal cycles, pressure changes etc... trying to find all of the bad units with hidden faults as well as find if one particular part is a common failure point among them. This same process extends to the components. For example TI sells special military and aerospace grade versions of a lot of there chips, but while the regular version you buy on digikey costs $1.50 the special high rel version of the chip costs $100 even tho its the same die inside. Only difference is that the high reliability version was put inside a better package and put trough a grueling series of tests lasting perhaps many days to make sure the chip really really really works. But for a typical commercial product its easier and cheaper to just warranty the product if on a very very rare chance that chip stops working.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 09, 2021, 05:11:47 pm
content: Unless you were designing a safety-critical device, testing internal blocks of some MCU upon start up looks extremely overkill.I don't think I've ever done this, except sometimes for Flash, as others have suggested, knowing that's something that is more likely to "fail" over time.If internal RAM is borked in some way, chances are the whole CPU may be damaged enough that running any code on it may fail anyway.Now yes, for some external peripherals, that could be a good idea. Again I would personally bother only for a device that is at least remotely critical. Beware of overengineering.

author: nctnico
author_rank: Super Contributor
timestamp: August 09, 2021, 05:26:26 pm
content: Quote from: SiliconWizard on August 09, 2021, 05:11:47 pmI agree. I'd only test safety critical things. One example where I implemented a system integrity test is a controller for extremely high pressures. This does some checks on various actuators by reading back the current / voltage send to the actuator so it can check whether the actuator is actually connected or not.But in the end such checks can backfire as well. If a check fails due to limits which are too narrow or a circuit fails then the device may shut down unnecessary making the problem worse instead of better. For example: In a distant past I worked at a repair department for mainframe computer hardware. They had one system that would reboot spontaneously every now and then. After a lot of searching it turned out an ADC used for monitoring the mains voltage went bad. After replacing the ADC, the system worked fine again.

author: ejeffrey
author_rank: Super Contributor
timestamp: August 09, 2021, 06:00:39 pm
content: In safety critical devices this makes sense, and I would imagine that industries that do this have standards on this.For non-critical applications? I wouldn't bother unless there is something in particular you are worried about. For instance a flash CRC test might make sense if you are operating at elevated temperature where flash degradation is a serious problem or if you have field updates possible that might leave flash in a corrupted state. If you are interested in detecting manufacturing faults, consider just doing it at manufacturing time where you can actually do something about it.

author: Silenos
author_rank: Regular Contributor
timestamp: August 10, 2021, 08:42:24 am
content: @peter-h:You don't test the memory or w/e of mcus as they already come factory tested.You do test the target functionality of assembled devices in programming-testing beds/rigs. That's much, much higher chance to have tombstoned resistor, mishandassembled some connector or a guy from supply department bought dodgy capacitors with deteriorating specs.Then you do test samples against common standards (electrical safety, enviromentals, markings, emi, etc) then against any special/brand standards, if any (ex, medical, mil/stanags, automotive, aerospace....). You do attach to your product a declaration of conformity, don't you?Quote from: Berni on August 09, 2021, 04:02:32 pmIf xrays are used in medical or some things like those airport scanners, they do nothing to electronics, the bands and energies are really thought that way... forget about lead for electronics for this.What actually tears electronics apart is gamma flux from sources like cobalt or caesium. And "few centimeters" of lead will attenuate such a flux maybe by a half, and that's barely anything against it.

author: Kleinstein
author_rank: Super Contributor
timestamp: August 10, 2021, 10:07:09 am
content: For critical applications it is requited to do a memory test for the RAM and other components too. The test at the factory is usually on a rather short one, unless you get space or similar qualified parts. Even than there is a chance that failures come up later, e.g. ESD or radiation. The RAM test would usually be on turn on and maybe in a separate burn in phase of the product, rarely in real time while the µC is actually in use.SRAM is usually more reliable than DRAM, but it still make sense to test it, when there is an opportunity / time.Some µCs include parity and maybe even error correction for the SRAM - so failures do happen and a factory test can not catch them all.