Plans for a Yellowstone Tester
With Yellowstone hardware development hopefully approaching completion, I’ve started thinking more about the design for an automated tester. As long as I’m hand-assembling one board at a time, I can throw it in my Apple IIe and try exercising some disk drives to confirm everything’s working, but that won’t scale up to dozens or hundreds of boards. I need some kind of testing device where I can plug in a newly-assembled Yellowstone card, and have it power the card, program the FPGA, test all the I/Os, and report success or failure – all with the push of a single button.
This will be a custom-made tester board with a 50 pin edge connector socket, along with a pair of 10 x 2 pin rectangular connectors for disk cables. The new Yellowstone card will be inserted into the edge connector socket, and two ribbon cables will connect the card’s disk connectors to the tester board, providing full access to all the inputs and outputs of the Yellowstone card.
Microcontroller Brains
The tester board will be powered by a microcontroller, so I can write test routines in regular C code: set the inputs to a particular state, confirm the outputs are as expected, repeat a zillion times for all the different test cases. But what microcontroller to use, and how to incorporate it?
Since the tester board is essentially a one-off and I’ll only ever build two or three of them, there’s no reason to incorporate a bare microcontroller onto the board. Instead I plan to use a pre-made microcontroller module with DIP pins, like an Arduino or Teensy or STM32 “blue pill”, and plug it into a socket on the tester board. That way all the brains will be pre-made, and the tester board will only need to contain the necessary connectors, control buttons, LCD, and other support components.
Ideally I’d also like the tester board to include an SD card socket, for loading data like the bit file for FPGA programming, the expected value of Yellowstone ROM locations, and maybe even the set of test vectors. While some or all of this could probably be compiled directly into the microcontroller program, it will be easier to provide updates as files on an SD card. This is especially true if the test board is stored and used at some third-party PCB assembly facility where they might not have the tools or time to easily flash a new microcontroller program. The SD card socket could be part of the pre-made microcontroller module, or it could be something I build into the test board.
So Many Pins
The biggest challenge here is the number of I/O pins involved in testing. At the 50 pin card edge connector, there are 32 pins that must be tested (the other 18 aren’t used). Each of the 10 x 2 disk connectors has another 16 pins that require testing. Then there must also be about a dozen more pins for things like control buttons, the LCD display, and enable signals for I/O buffers on the test board. All together, I’m looking at about 70-80 I/Os, which is a lot!
Although there are a few microcontroller modules with 70-80 I/Os, I think a better path may be to use port expanders or shift registers with a smaller microcontroller. The sweet spot seems to be around 32-40 I/Os, and there are many microcontroller module options in this range. But some care will be required when deciding how to map I/O signals to the port expanders. It won’t be possible to change all the I/Os simultaneously, and some I/Os may briefly adopt wrong values while new values are loaded. I’ll need to make sure that this won’t cause any problems for Yellowstone, and that any critical signals are provided directly from the microcontroller if they must be glitchless.
The Paradox of Choice
Some leading candidates here would be the STM32 blue pill or black pill, or a Teensy. The Teensy 3.5 in particular has the advantages of 5V-tolerant inputs and a built-in SD card socket, as well as 40 GPIOs. The blue and black pills are cheap, have 32 GPIOs, and have an enthusiastic support community, but they don’t have an SD socket or 5V-tolerant I/O.
But there’s a secondary goal for this tester board, and that’s to get familiar with a modern 32-bit microcontroller I might someday incorporate into a future project. I could definitely see this happening with the blue or black pill, since STM32 is a popular platform, and it wouldn’t be difficult to incorporate another member of the STM32 family directly into a new BMOW gizmo. But the Teensy is based on a Freescale microcontroller that’s much less well-known. While it’s well-supported on a Teensy board and inside the Teensy development environment, my sense is that I’d be swimming upstream if I ever tried to incorporate a Freescale MK64FX512 directly into a future BMOW creation.
Honorable mention goes to the Atmel (now Microchip) ATSAMD51, included in some microcontroller modules like Adafruit’s Metro M4 Express and Grand Central M4 Express. These have the advantage of using the same development tools I’m already familiar with from doing 8-bit AVR work, and in fact I already have a Metro M4 Feat. But there doesn’t seem to be a big community around ATSAMD51 boards outside of these Adafruit examples. Adafruit says their Arduino board support package has “lots of stuff working” but they are primarily targeting CircuitPython.
For simplicity’s sake, I will probably be programming the tester board’s microcontroller with the Arduino IDE. Even though I sometimes dismiss Arduino as being for “noobs”, I don’t really need access to any fancy hardware features here. I just need a lot of I/O pins, a generous amount of RAM and ROM, and a decent clock speed. The last time I experimented with full C/C++ ARM development environments, I got so bogged down in installing and configuring IAR / Keil / CooCox / YAGARTO / Crossworks that it was no fun at all.
I’m leaning towards STM32 here, because I think it would be the most interesting and useful to me in the long-term. If not the blue or black pill, then perhaps one of ST’s own evaluation boards, or another STM32 board, as long as it’s well-supported in the Arduino IDE and has a good community that can help answer questions.
Read 7 comments and join the conversation7 Comments so far
Leave a reply. For customer support issues, please use the Customer Support link instead of writing comments.
I cannot speak to the more hobby friendly toolchains available here (or which boards from this line would be best for you), but if the software support matches what you’d want, the STM32 Nucleo-144 series boards (https://www.st.com/resource/en/user_manual/dm00244518-stm32-nucleo144-boards-mb1137-stmicroelectronics.pdf) have roughly 70+ I/O pins on the external pin headers. I know they have some support for the Mbed environment, but I’ve never used that. ST also distributes a full IDE that their config tool will generate a project for, and I’ve heard it’s fairly pain-free to get working at that level.
I am a fan of the STM32 line and use them both at work and hobby (and they really are very popular in the hobby community). I wish I could point to an environment and say “Yes, that works and is simple” but I have not personally used any of them.
Thanks, I will check out the Nucleo. I see that ST now has a free own-branded IDE, STM32CubeIDE, which didn’t exist the last time I looked at this space. If it’s any good, maybe that would make the decision easier.
Steve: though unlikely to apply to your test fixture, consider this tip on adding dummy termination resistors pads for future prototyping efforts.
https://twitter.com/jaydcarlson/status/1427722050005831682?s=21
> While it’s well-supported on a Teensy board and inside the Teensy development environment, my sense is that I’d be swimming upstream if I ever tried to incorporate a Freescale MK64FX512 directly into a future BMOW creation.
#^&@%*#!
Yes.
https://www.eevblog.com/forum/microcontrollers/clock-not-runningtrying-to-move-teensy3-2-project-bare-mk20dx/
I’m somewhat partial to the Cypress PSOC, since it is the only ARM-based device I know which has true five-volt I/O. The CY8CKIT-059, $15 from Digi-Key, combines a cute little evaluation board with has two rows of 26 0.1″-spaced pins, about 0.8″ apart (not sure if it would fit in a 64-pin socket, but I’d guess it would). with a break-away on-board USB-port-equipped programmer.
This ended up being a bit longer of a rant than intended, that isn’t as cut and dry of a point as I meant to make when I started. Sorry about that.
My opinions on the PSoC lines are mixed. As John points out, they are one of the few modern ARM MCU lines that have true 5V operation. Additionally, if your project neatly fits into what they are capable of (including some very nice analog capabilities, and a good CapSense coree), then you can have a nice and neat simple system. Plus the vendor IDE is fully integrated in a way that everyone else only dreams of.
The bad:
The IDE is practically required for at least partial development, and it’s not what I’d call great. It’s a better IDE than the Arduino environment, but that’s a low bar.
When it works, it’s great, but if it doesn’t like what you are trying to do then you are in trouble. Specifically, I’ve had things that the IDE and spec sheets say work, fail in subtle ways resulting in extra respins because trying to route two internally generated signals via the internal analog routing bus to the internal ADC only works for one signal.
It’s all magic code generator bits (at a far more in-depth level than normal) and you are not expected to ever know what a hardware register is. See my point above.
Or docs that say that “these flash rows are for user purposes”, but their BLE library for that chip erases them (but doesn’t actually use them anyway) at undetermined times. I don’t know if that’s documented now, but it certainly wasn’t at the time.
This was a hard learned lesson when we had a product (over 50k shipped to date) using the PSoC 4 BLE line because we wanted the exact things that line was good at. Fast time to market, 5V operation, internal analog things (op-amps, etc), as well as some custom digital logic bits, but it turned out to be a big headache. I don’t doubt that there’s lots of even higher volumes successfully using the PSoC lines, but this was my experience at work. And of course everything has their warts, and you can find no end of horror stories about pretty much everything, including my own preferred parts. I even have some of those too. I guess I would prefer the terrible bits to be in software I can adjust if need be, rather than in magic code generators that try to 100% hide everything. At least everyone else expects you to use the registers too, even if they have a code generator.
That said, I actually still stock some PSoC parts on my bench because for the simplest of things it’s easy to throw one at a one-off I want to spend a minimum amount of time on and I don’t need anything fancy, but I don’t want to solder a Teensy to the board.
I share the concerns about being stuck to development tools that aren’t the greatest, but I’ve yet to find any vendor I/O libraries I really thought seemed to be well designed; the PSOC libraries seemed about average. When using the basic 8-bit registered I/O blocks to interface to custom digital circuitry on the PSOC, code can read and write bits as it sees fit by simply reading or writing the appropriate I/O registers without having to go through API functions, so something like the design I did to drive ten strings of one-wire serial LEDs was pretty straightforward. Every 10us it samples the state of ten eight-bit registers from the CPU and an eleventh control register which will be used to produce the ten pulse-width-modulated outputs.
I wasn’t expecting that this tester board would need anything particularly exotic, but thought the ability to directly interface to 5-volt logic would be noteworthy even if one didn’t use anything other than directly-programmed I/O.