Customer Story: Success Isolating Board Issues for Repair Station
The customer needed an easy-to-use solution that would isolate failing components on bad i.MX6 (ARM® Cortex®-A9) boards. Kozio provided and demoed a DDR validation tool and a hardware test tool that found eMMC issues.
A senior design engineer was working with a new ARM® Cortex®-A9 board design using a Freescale i.MX6 processor. During the initial stages of this new product introduction, he received several boards from the CM all marked as “bad” boards. The boards would not boot and run their boot loader or operating system.
The challenge was to isolate the faulty hardware device (or devices) without having to replace multiple devices through a trial-and-error process. The designer did not want to replace the processor, DDR3 memory chips, and keep replacing devices until a board worked. Furthermore, the desire was to implement a reliable repair station process that could be used on all failing boards.
The customer sent Kozio a good board and a bad board. A week later, Kozio hosted a web demo to demonstrate VTOS DDR™ and VTOS Scan™ running on both boards.
Although the “bad” board would not boot and run the customer’s operating system, Kozio was able to load and run VTOS DDR and VTOS Scan firmware on both boards. The Kozio firmware only requires the processor and a UART or JTAG interface to be working.
The first step was to run VTOS DDR and validate all DDR3 chips on both boards. The address, data, burst, noise, and comprehensive DDR tests all passed. An optional step was taken to generate optimal DDR settings using VTOS DDR and compare those results to the customer’s DDR settings. Kozio did find differences between the customer’s settings and Kozio generated settings. However, both sets of DDR settings passed validation at room temperature; but they were not tried at extreme temperatures.
The next step was to run VTOS Scan™ Plus on both boards. This tool is used to test GPIO, I2C, SPI, UART, SD, eMMC, Eth PHY, and SDIO interfaces and devices. Kozio took the needed step to configure tests for most devices on the board design, with special focus on those devices used by the boot process and operating system. A special test case was used to validate the eMMC boot device. Three different checksum tests were added to test the same eMMC device. Before each checksum test though, the operating bus width was set to 1, 4, and then 8. On the good board, all three checksum tests passed at all three bus widths. For the bad board, the checksum test passed when using a width of 1, but failed at widths of 4 and 8. This test proved that the eMMC device was not working properly, and not programmed correctly. The test was able to isolate the issue down to 1 of 7 possible signals to the device.
VTOS Scan™ provides many low-level commands that could be used to probe the failing board further. For example, the GPIO Write command could be added to drive the signals to each of the eMMC pads, once the part is removed. This additional step would prove out if there was an issue with the board traces or the eMMC part itself.