Sunday, February 16, 2020

Pi Board Automated Testing - Part 1 Introduction

I have a weakness for Raspberry Pi clones. I like how you can pack such a leave large amount of variety and power in a small and consistent form factor. As part of my day job, I often have to evaluate new SoCs or SoC IP cores (e.g. GPUs), and I almost always tend to gravitate toward finding a SBC in Raspberry Pi form factor for these evaluations if at all possible. This also involves using OpenEmbedded and the Yocto Project to run Linux on the SBCs, since I'm an active community member of both projects and also use them extensively at my day job.

After acquiring my 5th such SBC, managing them started to become ungainly. Each board requires at least 3 cables for the tests I was running (power, serial terminal, ethernet, and occasionally mouse, keyboard and HDMI), and shuffling them around was beginning to be a pain, particularly when I wanted to try the same build across different devices at the same time for testing, evaluation, and comparision purposes. Further complicating this setup was that each device needed a unique power supply, and the serial terminal is usually exposed as bare pins on the board (e.g. on the 40-pin pi header) meaning that constantly connecting and disconnecting it was annoying and error prone.

So, I set about trying to fix this. My initial goal was to create some sort of fixture that I could mount multiple SBCs on that would only require 3 connections for my core use cases: 1 ethernet cable that I could attach to my PC to network all of them (via a gigabit switch), 1 USB cable to access all of the serial consoles (via a USB hub and USB serial converters), and 1 power cable to power all the boards, ethernet switch, and USB hub.

I had a few basic requirements for this project:
  1. No complex fabrication. I tried not to use materials or construction methods that require anything more than basic tools; I don't own a 3D printer, or a CNC machine, so if I can't hammer, saw, drill, or glue it, it's not getting built. In fact, most of the structural components were scraps I had lying in my garage.
  2. Use as much off the shelf components as possible, and try to keep them cheap. The boards I'm testing max out around $100 each and most are less than that, so it's hard to justify spending a ton of (my own) money to test them.
  3. the fixture should support at least 6 boards at a time. I feel like this is a reasonable lower limit for a test fixture.
  4. The fixture should be transportable. I often have to move it around, so it shouldn't be too heavy, ungainly, or require a lot of setup.
  5. Reasonable access to the I/O of each board; namely the HDMI, USB, SD card, and Ethernet ports. These are the peripherals I use the most in my evaluations so I want to be able to access them easily on each board. Access to the 40-pin headers is nice, but secondary.
After putting some thought into this, I realize that it might be possible to use this setup to do automated board testing with a few minor tweaks. The first extra thing required was a way to remotely power cycle the devices, which I designed into the fixture. The second thing required was a way to get code running on the remote devices; there are a number of ways to accomplish this, but I really wanted some mechanism where by the test controller could write a complete image to the device under test's SD card while it was powered off, then power on the device and have it boot from that card. There are 2 reasons for this:
  1. Often one of the hardest parts of bringing up support for these boards is the bootloader configuration. Being able to flash an SD card fresh each time ensures that this is adequately tested
  2. This also ensures that the test can be run regardless of the state of the device before test, which should help keep the tests stable.
Fortunately, the internet delivered and I discovered SDWire which should perfectly fit my bill. The only real requirement it added to my fixture was that each board now required a extra USB connection to the USB hub so that the SDwire adapter could be accessed. I was unable to find anywhere where these could be reasonably purchased pre-made, so I'm have to build them from scratch and they are one of the few exceptions to my simple construction techniques.

As of this writing, the main fixture is completed, but I do not yet have the SDWire adapter built for a complete automated testing solution. Here is a picture of the completed fixture:


I will go into more detail about the different components of the fixture, how I built it, why I made some of the choices I did, and an overview of the 5 SBCs I'm currently using in subsequent blog posts.

No comments:

Post a Comment