4
\$\begingroup\$

My question is following:

Assuming I have developed some embedded controller(board) which has some tens of digital inputs and outputs. It has embedded firmware, which performs some logical functions. I have an automatic test stand which allows functional testing of production boards. It can simulate pretty any input signal combination and read, what controller provides on it's outputs. It can also, for example, switch on and off or swing power supply voltage to check correct operation in different conditions.

Now the point - are there any common methodologies of generating test vectors which would allow 100% testing coverage of my HW and at the best with minimum amount of tests? E.g. I want my controller to be 100% tested. Currently all boards are tested manualy, but this is time-consuming and I'm sure I don't get 100% coverage.

\$\endgroup\$
  • \$\begingroup\$ 100% coverage of the software,too? I ask, because that's what was required of some medical devices I worked on. Every single line of code, regardless of where it was located (library, O/S, etc.) had to be proven as executed by the testing. (I might argue that your hardware isn't 100% tested until your software is also 100% tested, since the software may change the state of I/O pins -- whether inputs or outputs or peripheral functionality.) \$\endgroup\$ – jonk May 4 '18 at 17:16
  • \$\begingroup\$ Jonk, yes, this might be even better, as my controller used in lifting equipment, e.g has some safety circuits, which are 100% hardware, offcourse. But software also critical. How you generate test cases for you? \$\endgroup\$ – syoma May 5 '18 at 5:30
  • \$\begingroup\$ An ICE system can capture system traces in order to prove execution coverage of the code. JTAG debugging can be used, tediously, to achieve the same by setting breakpoints and verifying they are reached. My end of things in the medical case was the software. Every single routine was provided every single possible input and every possible output was mapped for monotonicity, where appropriate, and behavior generally, otherwise. No software bug has ever been found in that device in more than 20 years of operation. But work went into that verification, too. I was curious if you wanted this, too. \$\endgroup\$ – jonk May 5 '18 at 5:52
0
\$\begingroup\$

I have created test equipment that has two programs, one for testing the hardware and software in one go, then the main program that is to control I/O and communications.

This took a while but was well worth it in the end as hundreds of units are being built each year. As the test equipment was thrown together and does the job I am currently creating a new piece of hardware (Software driven) that completes the task in under a minute (The existing test can take +10 minutes), this in mind requires me to think of all possible I/O and communications needed to complete the tests. What I have found is to test the test equipment in stages, only adjust 1 part of the code at a time and to document any findings. This way when looking back at the hardware and code you will know why it was done that way.

For example: I developed a test PCB with a PIC16 that tested all ports for dead shorts, this was then displayed on the LCD to indicate which pins were connected, however this was not as easy as first thought. From the above I documented each stage and completed the code and hardware this enabled me to create the finished product that we still use after 5 years. The hardware test was to short each pin to verify that it worked.

Likewise with RS232, RS485, MODBUS, Timers, RTOS systems *TCP/IP (*Which I am currently working on) are all tested as a block - documented and verified before moving on to the next stage. During this process the schematic is being developed and documented. Once I have determined all is ok a PCB will be made and populated, I will then test all functionality before production.

So the best thing to do is to test each and every part and each and every bit of code until you are 100% satisfied and that the hardware is 100% reliable.


Waffling on a bit there.. If you are only interested in digital I/O then you can create a bridged connection that outputs from one and inputs to another, This will test all of the I/O and allow you to test your code too. The use of resistor networks can also be used so that you have to drive the outputs to 0V in order to complete the input and output test. 10K resistor network should be more than enough.

\$\endgroup\$
0
\$\begingroup\$

I don't believe there is any one correct way to approach testing, the required test coverage ultimately depends on the criticality of the product.

When I sit down to create a new test jig for our workshop, the first thing I do is go through the schematic and identify each functional block of the circuit, write down the inputs and outputs (these could be digital or analogue) of the functional block then identify the pass/fail criteria, then I look for things that might cause false passes. e.g. If this component fails or is out of tolerance, will my test detect it? This might mean doing frequency response testing if it's an analogue circuit.

When we design our products, we design with testing in mind and ensure we include sufficient test points to be able to test at multiple points of a circuit with a bed of nails and not just the end point, which we will test again at final level testing.

We will usually have test firmware that we can communicate with and independently control the IO for our board level testing so that we can prove the hardware. Then the final product software is loaded on for final level testing.

I imagine your test hardware has some number of Digital IO and some number of analogue IO.

With software, I don't believe this needs to be 100% tested on each and every board, in my opinion the appropriate place for 100% testing of firmware is at the type testing stage of the product. The software should be revalidated for each modification to the code, but if your configuration management systems are adequate, then the same code will be loaded each time, and you already know it works, the rest is hardware testing.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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