Early microcontrollers had fixed I/O. It may have been possible to connect one of several internal peripherals to the I/O pins, but those pins were restricted and there was never an option of conditioning those outputs. Some modern microcontrollers not only have the ability to route the peripheral to any I/O pin, they also allow for configuration and customization of the outputs to suit a specific need. In this blog I describe how using this ability on the PSoC made testing the project much easier.
I have written about the approaches I take to testing products that I have designed (see The Art of Test, Part 1: Boards, Subassemblies, & Products, The Art of Test, Part 2: Controlling the Test and The Art of Test, Part 3: Lessons Learned). I was trying to build those concepts into a new product (see Figure 1) and as you can see there are quite a few I/O connections. The embedded micro was the PSoC5LP, a device which I have written about a lot, and am about to do it again!
I decided that the best way to approach this was to use a built-in test to activate outputs in response to certain inputs. This would make the test fixture much simpler since it would only require hardware and no additional programming of an external device.
A PSoC5LP based controller- most of the components are mounted on the underside. Note the tape used to protect the identity of those involved. It reminds me of a Dilbert cartoon. (Source: Author)
There was one issue that niggled. The product had a serial port with an RS-485 connection (half duplex) using the ubiquitous MAX485. How do you test that without some form of external UART? You could use a ‘scope to check the reception, but what about data going in the opposite direction? Back in the day there was a transponding UART from Motorola (the MC14469), but it is obsolete so that idea is a non-starter.
I rationalized that I wasn’t trying to check that the UART was operational, but that the supporting hardware was OK. So, all I had to do was stimulate the output from the micro in one test, and in a second stimulate the input to the micro and read that. I could have used the break feature of a UART (if it is implemented, and in the case of the PSoC5LP it is) although it involves extra interrupts and truth be told, the idea didn’t occur to me until writing this blog.
Typical embedded UART with semi-dedicated I/O pins on the micro. (Source: Author/PSoC Creator)
On a typical micro, the UART connections are brought out to one or more sets of I/O pins and then enabled by means of configuration registers as in Figure 2. On some reconfigurable micros and the PSoC5LP in particular, you can add registers and interpose devices between the UART pins and the physical I/O pins of the micro as shown in Figure 3.
Hardware configuration to allow re-configuring outputs for test. (Source: Author/PSoC Creator)
The output pins from the UART go to the I/O pins via a multiplexer. The control register selects the multiplexer port so that the micro can directly control the output pins precluding the UART completely. The Rx input is fed to a digital input register in parallel to the UART Rx input.
When bit 2 of the control register is low, the UART outputs are connected to physical output pins and the UART will operate as normal. The Tx pin is wired externally on the PCB to the DI pin of the MAX485. The TxEN pin is used to control the direction of data flow (!RE and DE shorted together on MAX485). The RO pin of the MAX485 drives the Rx input pin. When bit 2 of the control register is set to high (in the test software), the other two Control Register bits are connected to the physical output pins. The micro can then set those pins to generate a hardware signal to visually check the output. The input can be read in on a Status Reg when the direction of the MAX485 is changed via the TxEN output.
Not only does this allow reconfiguration internal to the device, I didn’t have to change my PCB either. All I had to create was a small patch board with another MAX485 and an LED to indicate the state of the output, and two switches- one changed the direction of the communication and the second could be read by the Device Under Test.
Don’t you just love configurability!