When you're building a commercial product*, being able to automatically verify each unit can bring good value.

Placing the device in a test jig and have it programmed and tested automatically can improve efficiency and quality.

The XDS110 debug probe has some support for that.

It can

• program your device,
• script execution (where you can set and modify conditions, validate and report state at a particular source line, etc ...),
• interact with on-board UART (at the logic level),
• can deliver power to your device < 400 mA and

• has 2 input and output pins that you can use in the automation.

In situations where testing your design doesn't need a full setup with data acquisition and oscilloscope, this can be a valuable setup.

UART

This is a fairly standard function when you work with an evaluation kit. Most manufacturers provide debug and UART support over USB.

In a test situation, also when your design does not need serial communication, you can use this to exchange data between the harware and the debugger.

You can embed debug specific UART commands in the firmware that aren't part of production firmware that help the automation.

You first load the debug firmware and run test cases that rely on that feature.

Then you load the production firmware and run the tests that don't need this interaction.

For designs that have serial communication as a production feature, you can use the debugger to test that.

The debugger's TX connects to the controllers RX and vice versa.

GPIO

The XDS110 has 2 input and two output pins that you can use in your test setup.

The core intent of these pins is to control boot modes of the unit under test.

However, they are plain inputs and outputs, so you can use them in any way you want during the test process.

The output pins can be used to trigger an activity or simulate inputs. The inputs can validate logic levels.

CCS comes with a command line utility called dbgjtag that can set and read the pins.

To drive the debugger's output pins 0 or 1 (both low, pin 1 high, pin 2 high, 1 and 2 high):

ccs\ccs_base\common\uscif>dbgjtag -f @xds110 -Y gpiopins, config=0x3, write=0x0
ccs\ccs_base\common\uscif>dbgjtag -f @xds110 -Y gpiopins, config=0x3, write=0x1
ccs\ccs_base\common\uscif>dbgjtag -f @xds110 -Y gpiopins, config=0x3, write=0x2
ccs\ccs_base\common\uscif>dbgjtag -f @xds110 -Y gpiopins, config=0x3, write=0x3

On the input side, the command line does not mask.

ccs\ccs_base\common\uscif>dbgjtag -f @xds110 -Y gpiopins, read=yes

Our two input pins are the two lowest bits of a LSB 4 bit port.

If both are high the utility returns: 0x0f. (0b1111)

If input pin 0 is low, the return value is 0x0b. (0b1011)

If 1 is low, 0x0 (0b0111)

Both low gives 0x03 (0011).

You can use a scripting language or a workflow environment such as LabVIEW to integrate these 4 GPIOs in your test set.

When you need more (8) inputs or outputs, have a look at this project: SCPI on a Raspberry Pi: LabVIEW Driver for LAB Switch.

* automating the product validation is also useful when you're designing a single prototype. It's a good way to validate that you did not break functionality after changing hardware or firmware.

If you design a test environment, you don't have to repeat manual testing ad infinitum. You become sloppy at that after a while anyways.