PROJECTS
Share article
Written by: Kristian Husevåg Krohn (Senior Development Engineer)
Hardware can be faulty, sorting out the bad ones from the good ones at an early stage can lead to less waste in production by not continue the product assembly with faulty components.
When developing a production test application for high volume production it is wise to try to map out some design goals beforehand, usually they look something like this:
A reasonable abstraction to start on is on top of the driver level, this will abstract out the nitty gritty details of each peripheral but is sufficiently low to not be much affected by the quirks of your application code. This will also help keeping the production tests quite self-contained and will hopefully not break when a trigger-happy application developer bumps a library. Another good idea can be to make a framework to put all the tests in, this way it’s easier to enforce standardized test execution, test documentation with coverage and usage, logging, and communication with the test-machine. All this will make scripting the test procedure a breeze either in the test-machine or on target and make things quite easy to maintain in the future.
When defining the set of features included in the production test framework, I prefer to not get in the way of the developer that is actually going to write tests (myself) by having the tests as a function pointers to the good old int test_whatever(const char **argv, int argc) and passing arguments just like a regular application. I like to think of the framework as a program of programs. When registering a test in the framework, I prefer to try to do that without cluttering up the framework itself and keep everything related to one test contained in a single file and control which tests to be built in the Makefile/CMakeLists.txt. When it comes to logging, I prefer to supply my own print functions so I can print to both stdout and a file.
A typical case for a production test is peripherals to the CPU. You don’t need to test every functionality of the peripheral. The chip/module itself it most likely good and tested by the chip manufacturer, the big unknown here is your own PCBA. When you can communicate with the peripheral, it’s probably good, try to keep your tests to the same level. An exception is when the peripheral you’re communicating with is connected to something more. Let’s say you have an external Ethernet controller, which in turn is connected to a Ethernet PHY and through some magnetics and out to the RJ45 jack. To have some level of confidence that Ethernet is working you’ll have to test the whole chain, either with a loopback cable or connect it to a switch to see that you get link. It is however enough to have link to be able to say the Ethernet is working and anything more will slow down the test execution.
This will become a really handy dandy tool for the other developers, testers and other personnel on the project. Although it might be ok to add tests that aren’t going to be used in production it’s important to not lose focus on the target here, especially when project management or sales finds out about this amazing tool that can make the hardware do stuff long before the product is finished.
One final note: you probably don’t want to leave the tool on target when shipping the product to customers. First, it doesn’t look good to have your internal production tools on a device you’re shipping to customers and second, you might have some functionality in it that you don’t want customers to fiddle with, like setting power rails to the point where the blue smoke starts to come out.
So to summarize: Test hardware, not software and plan for scaling, scripting and rapid change of the test set.
R&D Manager
https://rd-datarespons.no/wp-content/uploads/2024/04/iStock-114314994.jpg
836
1254
Henrik Eriksen
https://rd-datarespons.no/wp-content/uploads/2024/04/RD-Akkodis-logo_bigger.svg
Henrik Eriksen2024-04-15 10:44:552024-04-17 08:52:57Using const in C++
https://rd-datarespons.no/wp-content/uploads/2024/01/iStock-1494104649_2.jpg
768
1095
Henrik Eriksen
https://rd-datarespons.no/wp-content/uploads/2024/04/RD-Akkodis-logo_bigger.svg
Henrik Eriksen2024-01-08 09:16:462024-01-10 08:54:03Exploring a Safe Integration of AI and Business
https://rd-datarespons.no/wp-content/uploads/2023/08/iStock-858053070-2.jpg
836
1254
Øystein Molvik
https://rd-datarespons.no/wp-content/uploads/2024/04/RD-Akkodis-logo_bigger.svg
Øystein Molvik2023-10-05 12:09:402023-10-05 13:08:42Sensor Synchronization and PTP
https://rd-datarespons.no/wp-content/uploads/2024/04/iStock-114314994.jpg
836
1254
Henrik Eriksen
https://rd-datarespons.no/wp-content/uploads/2024/04/RD-Akkodis-logo_bigger.svg
Henrik Eriksen2024-04-15 10:44:552024-04-17 08:52:57Using const in C++
https://rd-datarespons.no/wp-content/uploads/2024/01/iStock-1494104649_2.jpg
768
1095
Henrik Eriksen
https://rd-datarespons.no/wp-content/uploads/2024/04/RD-Akkodis-logo_bigger.svg
Henrik Eriksen2024-01-08 09:16:462024-01-10 08:54:03Exploring a Safe Integration of AI and Business
https://rd-datarespons.no/wp-content/uploads/2023/08/iStock-858053070-2.jpg
836
1254
Øystein Molvik
https://rd-datarespons.no/wp-content/uploads/2024/04/RD-Akkodis-logo_bigger.svg
Øystein Molvik2023-10-05 12:09:402023-10-05 13:08:42Sensor Synchronization and PTP
Secure boot