Testing

Exclave: testing framework --- LCA2018 Talk, or via YouTube (from Phil's mail about it)

Glossary:

  • Fixture: Hardware and software that is not part of the production device which is used to perform and evaluate the results of tests. Processor which coordinates tests is referred to as the "test host".
  • DUT (Device Under Test): The device whose quality we wish to qualify using the results of tests.

Initial Board Bring-up

  1. Does power work? Measure the voltages, yes no. (This seems like a good application of a hardware fixture, especially if we want to do this for production boards before going on to the subsequent tests.) Voltages to test: 1.5V (DDR3), …
  2. Does plugging in only USB-OTG have it (DS-113?) show up on (test host's?)"lsusb", yes no?
  3. Load the FEL. Does that work, yes no?
  4. Now does loading u-boot directly into DDR3 RAM work, yes, no?

The FEL (u-boot-spl) loader has a nice debug feature of displaying a few lines of early UART so that's a really good way to tell if the A20's alive.

External Interfaces

EOMA68 Connector

The microdesktop 1.7 brings everything out. as it's only 68 pins, 24 of which are RGB/TTL, 4 are power, 8 are unused USB3, 7 are for micro-sd and 4 are for USB2, there's actually not a lot left.

Pin Count Interface EOMA68 Pins
1 PWM GPIO(10) 22
4 EINT-capable GPIO(11,16,17,18) 32,9,56,20
3 dedicated GPIO(19,20,21) 54,21,55
22 RGB/TTL 2-4,6-8,10-14,36-38,40-42,44-48
4 USB2 30,64,34,68
8 USB3.1 (unused) 25-28,59-62
2 I2C 15,49
4-6? SPI 1,5,35,39, 17?,51?
6 SD/MMC 16,18,19,50,52,53
2 UART 23,57
4 PWR (5.0V) 24,29,58,63
4 GROUND 31,33,65,67
1 POWER# 43
1 VREF-TTL 66

1 PWM GPIO, 4 explicitly EINT-capable GPIO pins, 4 dedicated GPIO pins, additional GPIO multiplexing pins on other functions, 18-pin RGB/TTL, USB2, USB3.1, I2C, SPI, SD/MMC, UART are included in the Version 1.0 specification.

  • SD/MMC: Compile u-boot to look for a particular micro-sd card slot, which it will scan, and show debug messages "SD card detected" and so on. Commands can be issued which list the partitions and so on.
  • UART: Add a USB-to-UART adapter onto a "test" microdesktop unit, if there's output on the console and it's not garbage, that's good enough.
    This could be faster and more automated if we attached a process to the serial device on the UART on both test host and DUT. The process on the DUT could send an initial "ready tx" message to the test host which could respond with a "test rx" message which the DUT would read and respond with a pre-ordained "test tx" message to the test host.
  • USB: Attach two USB devices with unique IDs (say, CP2012 - you can program those through USB connection) and make sure they're recognized - in case of CP2012, you can make a loopback test of their UART, just to make sure data passes through.
  • I2C: EEPROM on-board the Micro-desktop PCB
    Scan the I2C bus (lmsensors debian package), see if a peripheral at address 0x51 comes up, if it does great. It's a few lines of shell script.
  • SPI
  • VESA DDC: Make sure VGA display is properly identified via VGA DDC probing. Compare value retrieved to accepted EDID value.
  • RGB/TTL: Connect a VGA display to the VGA connector of the microdesktop board and observe display of correct picture at desired display resolution. Create picture of test pattern with color gradients.
  • GPIO: There's actually only a few pins spare, they're all on the 14-pin header of the microdesktop board. Except for two which are intended for bit-banging a separate I2C driver for VGA "EDID" detection....
    A simple program that tests GPIO, assuming that say 4 resistors are connected between 8 GPIOs in pairs, turning one into an input and the other an output, then setting 0 and 1 and seeing if it's read correctly... then inverting each pair (out becomes in, in becomes out) and re-running the test.
    Something in either c or python that uses the sunxi-3.4 gpio driver: [drivers/gpio/gpio-sunxi.c]
    That should be exposed as /dev/gpio which should in turn appear in either /sys or /proc... It should be a standard interface, with a standard way to set which banks are activated... You might have to do some digging.
    Microdesktop Expansion Connector (J5)[1]
pin(s) Net Name Candidate for GPIO tests
1,2,14 GND
12 VCC-3V3
19,20 VCC-5V0
3 PWRON
8 VREFTTL
4 EOMA68-UART_TX
6 EOMA68-UART_RX
16 EOMA68-I2C_SCL
18 EOMA68-I2C_SDA
10 VESA_SCL Y
13 VESA_SDA Y
5 SPI_SCK Y
7 SPI_CS Y
9 SPI_MISO Y
11 SPI_MOSI Y
15 EINT0 Y
17 GPIO_3 Y

GPIO Test Pin to Register Bit Mapping

EOMA[4] A20[5] DS113[3] microdesktop[2]
Net Name ball register CON15 pin J14 pin J5 pin Net Name
SPI_CLK D17 PI11 9 5 5 SPI_SCK
SPI_CE C17 PI10 10 39 7 SPI_CS
SPI_MISO D16 PI13 1 1 9 SPI_MISO
SPI_MOSI C16 PI12 2 35 11 SPI_MOSI
PWM B19 PI3 43 22 10 VESA_SCL
IR-RX A13 PB4 33 17 13 VESA_SDA
EINT0 A6 PH0 63 32 15 EINT0
IR-TX B14 PB3 34 51 17 GPIO_3

Micro HDMI Connector

Plug in a micro HDMI cable connected to a display capable of the maximum supported resolution and test detection of the display and proper display of a test image on the monitor. 24-bit/pixel 1920x1080 p60?

Micro SD Connector

Connect a micro SD cable to DUT and a suitable SD peripheral. Verify the processor can see the peripheral and interact with it. (Storage device? Mount a partition and read a test file.)

Micro USB-OTG Connector

References:

  1. Microdesktop Schematic v1.7, p. 2
  2. Ibid., p. 1
  3. DS-113 Schematic v2.7, p. 13
  4. [https://elinux.org/Embedded_Open_Modular_Architecture/EOMA68]
  5. A20 Datasheet V1.40, page 34