Hardware Testing "the other 83%"

The first task was to get some SMART Response XE devices. They are readily available on eBay.

All of the devices were purchased as sets of 32 to 40 devices and all were described as "working when removed from service". The problem was that "service" was back in 2011-2014. Worse still is that most of them were unceremoniously stuck in classroom closets with the batteries still inside. I took a guess that 25% would be worthless.

Before I knew what I had done I had over 500 devices arriving. I have a few really bad orders and received refunds  a also had three orders which contained NOS (new original stock) still in plastic wrap and never having batteries installed.

All I could do was visually inspect the devices when they arrived, remove any dead and often corroded batteries, perform some cleaning, and see what happened with new batteries.

What I really needed was a thorough smoketest for all the hardware. The test needed to cover everything and especially anything where corrosion could be.

SRXEcore Library and the SPI Development Adapter 

I located a few different open source code bases for the SMART Response XE hardware. I then set about to find the most up-to-date code. I merged from a couple different sources (being sure to include credits for original authors and sources). I then standardized the functions, added in some missing pieces, tested everything, and wrote full documentation.

One useful feature of the SRXEcore library is its "multi-personality" printf() functions. The printf() functions draw heavily from "tiny printf". However, the output of the print function may be directed to the LCD screen, the UART (see below), or the RF transceiver!

This was the genesis of the SRXEcore. To this library, I added font management and a series of higher level UI features specific to the SMART Response XE hardware.

The final step for the SRXEcore was to write a smoketest for all the SMART Response XE hardware. The test needed to verify the SPI interface, the LCD display, every key of the keyboard and the menu keys, the power button, internal FLASH chip, and the RF transceiver.

(the smoketest is included with the SRXEcore as it's "sample program")

Since there were a lot of SMART Response XE devices to test, I need an easy way to reprogram the devices. It was paramount to do this as easily as possible. Opening the case of every device was out of the question. Thankfully, the SPI GPIO pins of the ATMega128RFA1 are exposed through pads and hole in the battery compartment. 

There are 10 pins exposed from the battery compartment. SPI only needs 6. The other 4 were tied to JTAG but with a FUSE setting, they could be general purpose.

I revised the SRXEcore to include a bit-bang UART on one of the spare GPIO pins.

Armed with all of this data I designed a programming adapter. It has the 10 long pogo pins on one end, with a layout to match the holes in the SMART Response XE case. At the other end is the SPI connection. The remaining 4 GPIO are connected to a standard 0.1" header and LEDs (useful for debugging).

I tested over 500 devices with a failure rate of approx 17%. Most of these failures were directly attributed to corrosion on the PCB. There were some reoccurring failures. For example, a corroded trace would often cause a row of keys not to work. Corrosion around the interface pads or their traces resulted in flashing failures. A few were just DOA.
The smoketest resulted in 420 "good" devices.

Much later in the project, I found a need for getting screenshots from the SMART Response XE for writing documentation. The LCD driver supports reading but that capability was never exposed. I solution was to create a "renderer" in python.

The python screen grabber program runs on a computer and connects over UART to the bit-bang output from SRXEcore. When enabled, the SRXEcore streams commands over UART which mirror the updates to the LCD. The python code processes the stream...