One of the requirements of the JeeNode Zero rev4, is that each one has to be tested and then end up with the proper software loaded onto it. The obvious way to do this is to connect each board over FTDI after assembly, but since the headers are not soldered on at this stage, some sort of temporary hookup trick s needed.
Meet Fiddy, a 3D-printed clip which turns 6 “pogo pins” into a clip that can easily hold a PCB:
(Note: this image was shamelessly copied from Thingiverse)
This design was created and most generously shared by Timothy Reese, and there’s a very nice tutorial on the AdaFruit website about how to produce the clip and set it all up.
Ok, that should solve the initial upload, since FTDI with DTR and RTS hooked up is sufficient to re-program any STM32 chip via its built-in ROM boot loader. But what about testing?
The test requirement for this initial batch of JNZ rev4’s was kept relatively simple: make sure FTDI & µC work, verify that the LED works (it’s so easy to mount it the wrong way around!), and verify that the RFM69 module works for both transmit and receive. The reasoning is that with a working Forth interpreter installed, any special problems with a board can be tracked down in the field, since it’s easy to enter a bit of Forth and toggle any I/O pin, for example.
And of course, as part of the assembly process, all boards are visually inspected for obvious faults, such as “tombstones” (i.e. a tiny SMD resistor or capacitor ending up vertical due to excessive capillary pull on one side during reflow) and solder bridges between pins.
For testing the radio module, a second unit is needed. The approach selected as quick solution for now, was to take a Blue Pill with an RFM69 radio added, which listens to packets on a non-standard frequency, and then echoes a packet back.
The code for this Test Echo Node is quite simple - here’s the what the first version looked like:
: echo
870 rf.freq ! rf-init 0 rf-power
begin
rf-recv ?dup if rf-txtest then
again ;
echo
We set the radio to 870 MHz, well away from the 868 MHz band, and we set its transmit power to minimal so that it’s unlikely to disrupt anything over a few meters away. Then we continuously listen for a packet, and when received, we send out a packet with the length of that received packet. The contents really doesn’t matter - anything will work as basic reply.
With this approach we can let the Blue Pill echo continuously, while each new JNZs-under-test attempts to get a packet out and then read back a reply. On reception, we know it works.
This is the test setup, as actually used for the first batch of JNZs:
One requirement was that the JNZ should be tested without antenna attached, since that’s how these units are to be sent out. This is not so hard, given the proximity of the echo node, but it did require a bit of twiddling of RFM69 registers. And bumping the TX power a notch.
The last puzzle to solve was perhaps the most interesting one: how do you run a test on a fresh board and then end up with only the final release firmware once the test succeeds?
Thats’s were the flexibility of Mecrisp helps: we can create an image with all
the release code in it (always/board/core) and then append a test with its own
override of the init word.
When flashed this way, it starts the test init (since it’s the last one
defined in the dictionary), and the test will run. And now the trick: when the
test completes successfully, all it has to do is execute “<<<core>>>”. This
removes the test code from flash memory and resets the board.
Since the LED is turned on by default on the release image, seeing the LED turn on is a signal that the test completed successfully, and that the board can be removed and accepted.
The full test code can be found here, but an extract of the main logic is as follows:
: blip
870 rf.freq ! rf-init 8 rf-power
begin
i rf-txtest
5000 0 do
rf-recv ?dup if
<<<core>>> \ clears test code and does a s/w reset
then
loop
1000 ms
again ;
: init init led-off ( unattended ) blip ;
The actual code has some more refinements, but this’ll give you an idea of the whole process: the test runs, and once successful, it wipes itself, leaving the µC’s flash in its final release state.
It all worked like a charm. Of the 147 boards built, one probably has a short in the PCB and had to be rejected. For the rest, there were some issues with the soldering of the special (sideways-mounted!) LED, and a handful of tombstones. Each of these was fairly easy to spot and repair. One radio was mounted the wrong way around (doh!), and one µC chip ended up with its pads shifted over by one - nothing a bit of patience and heat couldn’t cure. So all in all, we had over 99% success rate, with > 90% of the boards coming out perfect right away, and the rest easily reworked and fixed. The software test was essential in catching all “outliers”.
The one downside which quickly became apparent, is that a complete firmware upload takes about 22s per board (the test is nearly instant). On a larger batch, that could well become a bottleneck - but a fix is already in the making: a new test jig will make the process 4x as fast by using the L052’s built-in ROM SPI-upload. Driven by Forth - probably an extra JNZ, in fact.