Presenting Built-In Self-Test Coverage - Page 1
Forum section: electronics / projects

author: ColdKeyboard
author_rank: Contributor
timestamp: February 27, 2018, 05:30:06 pm
content: I have a piece of code that performs self-test on various components of the board, like MCU, BLE, IMU, OLED, flash memory, and etc.What I'm trying to make is a document that would represent what these tests cover, or when you run the IMU test and it says "PASS", what does that actually mean. Or going from another direction, if I want to test BLE/OLED/MCU, what set of tests I need to run to have confidence that it's all working as expected.Now, I know how to represent this data in a text format or in some table but even when I try my best this information gets too convoluted, confusing and looks like someone just threw up a bunch of data and you need to make sense of it.What I'm looking for is something like industry standard way of representing this information, or best practice that would allow someone to take a look at a document and say: "Yes, this BLE test ensures that my chip is soldered properly, crystal is present and oscillating, firmware is running fine but it doesn't test the actual BLE antenna and tuning/matching component". Or from bottom up, someone says "I wan't to test that IMU is working properly, so I need to run these set of tests and they will ensure that chip is soldered properly, GPIOs are working, and device is registering 1G along X/Y/Z axis"Any suggestions, examples or pointers on what to look for would be very appreciated.Presenting Built-In Self-Test Coverage

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: February 27, 2018, 05:49:38 pm
content: For production test, the only thing you care about is failures, so you just need a single "PASS" indication at the end of all tests to show no failures.If display space is limited just stop at the first error - once you know something is bad, it can be put aside to investigate, and at that stage you don't really care how many things are bad, just that it did not pass.You have an OLED, so test that first, and then use it to display any errors. If you have read/write access to it you can write & readback a test pattern to confirm connection, but as you probably also want to detect bad pixels you probably want to display a few test patterns - at least all on and all off.Pretty much the only fails you'll see are bad connections, so if you can, for example, get a version number back from the BLE module that's probably enough. Of course if you want to be super-thorough you could try to talk to something over a BLE link.The IMU probably has some built-in test functionality that you could use.

author: ColdKeyboard
author_rank: Contributor
timestamp: February 27, 2018, 06:45:08 pm
content: Thank you Mike for detailed answer!I'm familiar with how production tests are designed and how they should work. The thing is I'm not the person designing production tests,however I want to make a document that will show what tests are available and what do they cover.What I hope to achieve with this document is help with two situations:Situation #1) I want to validate that component(s) are working, so I consult the document to see what set of tests I need to run and what they "guarantee"Situation #2) Someone told me they are running this set of tests and they are passing, I want to see what they are covering and what they are not covering.Something like spreadsheet matrix looks like the best option but I'm not sure if there is a better way or suggestions to avoid common pitfalls?