Design for Manufacturing

Guidelines for DUT design to facilitate manufacturing.

Firmware Update

Most products end up requiring firmware updates in the field, to fix (security) issues or deploy new features. Implementing this early in the development process allows leveraging this process during development, prototyping, manufacturing and RMA handling.

Many components used in connected devices support high-speed programming over standardized protocols. Consider designing the DUT such that these can be used early in the development process, even if the final product locks down access to these update methods.

  • BOOTP/TFTP

  • USB-DFU

  • USB-MSC

See also

One-Time Operations

Consider designing the DUT HW and FW such that the firmware can be programmed multiple times, without performing one-time operations.

This does entail a separate Provisioning process, either explicitly controlled from a PLT, or performed by the DUT FW upon first use, to handle one-time operations such as writing fuses or enabling readback protection.

Diagnostic Firmware

Ideally, the DUT firmware emits an unambiguous PASS/FAIL message containing all the information that needs to end up in the Test Report that can be obtained from firmware running on the DUT.

As of PLT-OS v1.10.x, the most straightforward way to accomplish this is by having the DUT firmware emit this information over UART.

See also

This reporting can be part of the functionality of the production firmware image that needs to end up in the finished DUT, or it can be implemented in a separate diagnostic firmware image that is programmed into the DUT during production testing, before replacing it with the production firmware image.

Tip

Generic diagnostic firmware images can be generated using:

  • PPC Yocto Layer (for Linux-based DUTs)

  • Zephyr (for Zephyr-supported MCUs)

See also