Manufacturing test SDK add on: Difference between revisions

From RidgeRun Developer Wiki
mNo edit summary
mNo edit summary
 
(5 intermediate revisions by the same user not shown)
Line 2: Line 2:
<tr>
<tr>
<td><div class="clear; float:right">__TOC__</div></td>
<td><div class="clear; float:right">__TOC__</div></td>
<td>
<td valign=top>
<html>
{{ContactUs Button}}
<div class="ecwid ecwid-SingleProduct ecwid-Product ecwid-Product-59350607" itemscope itemtype="http://schema.org/Product" data-single-product-id="59350607"><div itemprop="image"></div><div class="ecwid-title" itemprop="name"></div><div itemtype="http://schema.org/Offer" itemscope itemprop="offers"><div class="ecwid-productBrowser-price ecwid-price" itemprop="price"></div></div><div customprop="options"></div><div customprop="addtobag"></div></div><script type="text/javascript" src="https://app.ecwid.com/script.js?7804024&data_platform=singleproduct" charset="utf-8"></script><script type="text/javascript">xSingleProduct()</script>
</td>
</html>
</table>
For more information please visit our [http://www.ridgerun.com/#!store/pogiw/!/Manufacturing-tests/p/59350607/category=16360689 store] or [http://www.ridgerun.com/#!contact/c3vn contact us]
</td></tr></table>


A customized set of busybox shell scripts that run on the target device to exercise all the I/Os used in the product. These tests are useful for bringing up new hardware and on the assembly line for verifying the functionality of each board.  Manufacturing tests are customized based on the hardware design being tested.  All tests follow a simple go / no-go either by probing and querying the device via UART, SPI, I2C, GPIO or by simple user interaction ("press the button labeled XXX", "Did you see a green and white striped image on the display.").  Does not include integration of other external test apparatus.
A customized set of busybox shell scripts that run on the target device to exercise all the I/Os used in the product. These tests are useful for bringing up new hardware and on the assembly line for verifying the functionality of each board.  Manufacturing tests are customized based on the hardware design being tested.  All tests follow a simple go / no-go either by probing and querying the device via UART, SPI, I2C, GPIO or by simple user interaction ("press the button labeled XXX", "Did you see a green and white striped image on the display.").  Does not include integration of other external test apparatus.


= Philosophy =
== Philosophy ==


The purpose of a manufacturing test suite is two-fold:
The purpose of a manufacturing test suite is two-fold:
Line 31: Line 29:
When you purchase the RidgeRun's manufacturing test SDK add on, engineering hours are included for the development of custom test cases based on your hardware design.  Example custom test cases include testing gyros, accelerometers, camera sensors, video out, EEPROM programming and fuse burning, WiFi, etc.
When you purchase the RidgeRun's manufacturing test SDK add on, engineering hours are included for the development of custom test cases based on your hardware design.  Example custom test cases include testing gyros, accelerometers, camera sensors, video out, EEPROM programming and fuse burning, WiFi, etc.


= Hardware setup on manufacturing line =
== Hardware setup on manufacturing line ==


* A debug board / manufacturing harness is attached to the unit under test (UUT).
* A debug board / manufacturing harness is attached to the unit under test (UUT).
Line 47: Line 45:
* If a test fails, it is reported to the operator.  The user can mark the UUT as needed.  When it is repaired, the board can be tested again.
* If a test fails, it is reported to the operator.  The user can mark the UUT as needed.  When it is repaired, the board can be tested again.


[[Category:SDK]][[Category:SdkAddOn]]
[[Category:Old]]

Latest revision as of 18:29, 22 May 2024

A customized set of busybox shell scripts that run on the target device to exercise all the I/Os used in the product. These tests are useful for bringing up new hardware and on the assembly line for verifying the functionality of each board. Manufacturing tests are customized based on the hardware design being tested. All tests follow a simple go / no-go either by probing and querying the device via UART, SPI, I2C, GPIO or by simple user interaction ("press the button labeled XXX", "Did you see a green and white striped image on the display."). Does not include integration of other external test apparatus.

Philosophy

The purpose of a manufacturing test suite is two-fold:

  1. Verify the board is free from manufacturing defect.
  2. Program device specific values, such a Ethernet MAC address.

A good manufacturing test suite can be executed quickly, logs issues that are encountered, and can be rerun to test a repaired board. In more sophisticated environments, the logs may be uploaded to database.

Over the years, RidgeRun developed many different approaches for customer specific manufacturing tests. RidgeRun settled on using tests that run directly on the hardware as being the most reliable and easiest to keep running when manufacturing is done in batches where weeks may go by without boards needing testing. Running the tests on the hardware means the complexity is contained in the manufacturing test harness (if one is needed) and in the test code itself. Any PC can be used to execute the test without requiring a complex setup. Typically a USB-to-serial adaptor and an Ethernet interface is all that is needed on the PC used by the operator to run the tests.

RidgeRun's manufacturing test SDK add on comes in two parts:

  • Test execution framework and test cases for the I/Os build into the SoC.
  • Custom test cases based on the specific hardware design.

Since the I/Os on the SoC don't change (although your design may not use them all), the RidgeRun's manufacturing test SDK add on includes tests for serial, I2C, SPI, NAND, SD card, GPIOs, Ethernet, USB, etc.

When you purchase the RidgeRun's manufacturing test SDK add on, engineering hours are included for the development of custom test cases based on your hardware design. Example custom test cases include testing gyros, accelerometers, camera sensors, video out, EEPROM programming and fuse burning, WiFi, etc.

Hardware setup on manufacturing line

  • A debug board / manufacturing harness is attached to the unit under test (UUT).
  • The debug board configures the SoC boot select pins to boot from SD card. There is an SD card on the debug board with a RidgeRun provided set of manufacturing tests. This SC card image can be re-created from the customer's software repository.
  • The debug board has a serial connection to a Windows PC with TeraTerm installed.
  • TeraTerm is used for operator interaction and logging. Other options besides TeraTerm are available depending on customer requirements.
  • The testing operator clicks on a Windows desktop icon to start TeraTerm. There is a TeraTerm script that is run to enable logging. The operator need to enter-in / scan-in the UUT serial number.
  • The TeraTerm script prompts the user as necessary to turn on UUT. The script starts the manufacturing tests that run on the UUT.

Manufacturing test SDK add on

  • If a test fails, it is reported to the operator. The user can mark the UUT as needed. When it is repaired, the board can be tested again.
Retrieved from "https://developer.ridgerun.com/wiki/index.php?title=Manufacturing_test_SDK_add_on&oldid=54384"