• Please review our updated Terms and Rules here

Flip-Chip Module Tester, bring-up and experimentation

gwiley

Experienced Member
Joined
Nov 12, 2021
Messages
249
Location
San Diego, CA, USA
Recently put together an M-Series Flip-Chip Tester, the original design by Warren Stearns. This is based on the variation by MThompson and PCB by Vince that was modified to connect to an FTDI C232HM interface. In this variation, the MISO and MOSI signals of all 5 GPIO expander chips are tied to common MISO and MOSI signals and each GPIO expander has its own address.

However, instead of connecting to a PC via FTDI, the tester board is connected to one of the hardware SPI channels on the ESP32 module on the proto board at the left side of the photo. Also on the proto board is a microSD card interface which is connected to the same SPI channel as the tester but is enabled with a separate chip select signal.

It’s in the early stages, but using Arduino test code I’m able to read from and write to signals via the GPIO expanders and can do file operations with the microSD, confirming the two co-exist happily on the same SPI. There is one cut-and-jump on the microSD module that tri-states MISO when the SD chip select is inactive. Could’ve done the equivalent using an extra 74HC125 but didn’t want to wait an extra day or two to order the ‘125.

Have only just started porting the tester code over to the Arduino environment but have scoped out roughly what needs to be updated. Loaded the code into Microsoft Visual Studio to play with the code a bit first.

Later on, I might control the tester using an RPi or PC, but I’m quite familiar with the ESP32 and its cousin which are in many home automation devices in my house. For my experience, this seemed like an easy place to start.
Flip-Chip Tester 50pct.jpg
In the photo:
ESP32 on the proto board on the left, microSD interface standing up on the proto board. The microSD is for storing test vector files. Nothing wireless is being used on this ESP32, it’s just a CPU for this purpose… for the time being, anyway.

Tester board on the right with 4 SPI signals plus RESET-N cabled to the proto board. The three-conductor cable between PROBE signals and VPP and GND pins on the tester are to test reading from signals on the GPIO expanders. The Arduino test code configures the four PROBE signals as inputs with pullups so the PROBE points can be shorted to GND and confirm that data is read back properly. Test code also flashes the tester LEDs and the state of the LED signals is also read back properly. The tester PCB is slightly modified from the MThompson-vrs version.

The initial goals of this effort… play with the tester in various configurations to learn more about it through practical experience, and to be able to test M-series modules from my 8/L and some spare modules too.

I’ll post more when there’s progress, but I have upcoming travel which will certainly impact progress on fun PDP-8 stuff (again).
 
The C# libraries that I used with the Visual Studio C# code are absolute crap and really limit the performance of the tester. I started rewriting them, but didn't get far.

I bought a few Raspberry Pi Picos that I could use instead of the FTDI cable, and maybe to move some intelligence into the tester.
 
The C# libraries that I used with the Visual Studio C# code are absolute crap and really limit the performance of the tester. I started rewriting them, but didn't get far.
Good to know, thanks. I'll stay away from using the FTDI C232HM interface in Windows.
I bought a few Raspberry Pi Picos that I could use instead of the FTDI cable, and maybe to move some intelligence into the tester.
This sounds like the right thing. A small and fast micro does the real-time control of the tester. Would be nice to have the tester GUI on a PC controlling that MCU.
 
>This sounds like the right thing. A small and fast micro does the real-time control of the tester. Would be nice to have the tester GUI on a PC controlling that MCU.

I have the Windows GUI working well, and periodically work on things like manually controlling the pins on the tester. The FTDI C# library adds long wait states to the SPI so the tester speed is limited. My plan is to replace the FTDI cable with the Pi PICO, use the MS serial port libraries to talk to the PICO, and have the PICO do the serial to SPI translation.
 
Back from my trip so it's time to play with the tester again. Some code modifications were necessary to get this to run on the Arduino (ESP32). Commented out pieces of the original code rather than deleting and tried to change as little as possible. The interface to the tester board is through the hardware SPI in the ESP32, so that part is different compared to the original code. The test vector files are saved on a microSD card also connected to the ESP32's SPI.

An M113 board, 10 NAND gates, passes with the original M113.TST vector file.
M113 test in tester 50pct.jpg M113 test console output 50pct.jpg
There are still a ton of little things to be fixed but at least basic functions seem okay.

There are some hardware changes on the back of the board that aren't visible. I started off using hardware address enable (IOCON.HAEN = 1) but there was some whacky behavior with the MCP23S17 chips on the SO pins. For example, IC5 would respond to a read with either addresses 100 or 101. There's plenty of setup and hold time on the SI pins and it's only running at 5 MHz. Changed to separate hardware chip select signals for each MCP chip and now the selected chip responds only when it is selected.

Need to clean up the connection between the ESP32 and tester board and have better power delivery wiring, and test some of the more complicated modules.
Also have an RPi Pico that I want to try next, probably first just use slightly modified ESP32 Arduino code and then try out the Pico SDK
 
Had an opportunity to test about half of the PDP-8/L modules using the Stearns Flip Chip tester. I’ll create another thread about the 8/L experience and keep this thread on the topic of the tester. The ESP32 module has now been built onto a perf-board prototype module so the connections to the tester circuit board are now much shorter. I’ll post a photo later when I get home.

Based on the number of faulty M-series modules found, it’s clear that the tester saves a *huge* amount of time debugging a CPU! This is an incredible resource for the PDP-8 community. There are a good number of test files available that contain test vectors to test the modules.

There are still some issues with this ESP32 Arduino port of the tester software that I need to address. The run-once command isn’t so reliable. There are faults detected when good modules are tested, often when the number of vectors is large or if run-once is done repeatedly.

Running the scope loop is convenient and very reliable, and for me, this is most useful mode for debugging a module. The run-once does indicate which pins and on which cycles the faults are detected. While in the scope loop mode I learned that it would be useful to observe on the scope exactly which cycles have faults (rather than counting cycles from the start of the test) so I added a simple function in the tester software to generate a pulse on one of the ESP32 GPIO pins on every cycle where a fault is detected. Also added a testpoint on the ESP32 board to monitor this pulse using a scope probe. My scope can display only two channels so a practical setup is to connect the start-of-test testpoint on the tester board to the scope’s external trigger, view the error pulse (new ESP32 tespoint) on channel 2, and probe around the board as needed using the channel 1 probe.

Those four 18x2 headers with a jumper on each pair are quite convenient for probing signals on the board edge connector. The tester board silkscreen has each pin labelled so there’s no need to count the pins on the actual edge connector and remember to skip pin labels G, I, O, and Q. It’s also pretty easy to clip a scope probe with witch’s hat onto the jumper pins on the 18x2 headers.

The time per test vector cycle is a bit longer than I originally expected, but it makes sense now because I can appreciate that the tester needs to examine every edge connector pin on every cycle, or at least query the vector structure to determine whether each pin is relevant. This is only an issue when testing modules that produce single-shot events such as the M700 timing module.

I’ve modified the M700 prototype vector file to run as two separate test files: M700FIL to test the filter function and the M700TM which tests the timing pulse sequence. Both are scope loop tests.

The M700 is the most “analog” module that I’ve tested so far. Looking forward to test the green modules and some of the more complex digital functions toward the back of the 8/L.
 
Back
Top