June 2014 47
Testing BASIC
Stamp Modules
The first thing to realize is that these testers cannot
detect all issues or failures. The most obvious case is that
the Stamp cannot be detected by its editor or some other
communication error. The tester is designed to detect
issues with the interpreter chip, I/O pins, RAM, and a few
other elements. The code is designed to be as thorough as
possible. However, if you cannot get it onto the module,
then it is beyond the capabilities of this tester.
Internal/External
Testing
The first thing that needs to happen is you have to tell
the editor which Stamp it is testing. This is done by
selecting the appropriate Stamp Directive from the toolbar
or menu. The reason this is important is that the test code
uses conditional compilation to set up different
parameters and code blocks that are different for the
various models. If you don’t change the Stamp directive,
you will be instructed to do so when you download the
program and the editor detects a different model.
Bear in mind there is a verbose mode and a non-verbose mode. Parallax manufacturing uses the non-verbose mode for speed; tech support uses the verbose
mode to see exactly what is happening during a test.
These modes are set by a special constant toward the
beginning of the code. The default is to use verbose mode
which takes slightly longer to run, but gives details of each
test performed on that module.
Once the code has been downloaded to the target
module, it does the following:
• The OUTS register is checked for integrity, so it can
be used as a counter for the RAM test.
• Variable RAM is tested.
• If the module has scratchpad RAM, it is tested.
• I/O pin drivers are tested.
• I/O pins are tested via an external RC circuit.
What’s Going On
in There?
The OUTS register is checked first because in order to
test RAM, we need some way to keep track of the
address. However, we’re essentially destroying RAM, so
we can’t create a variable. Besides that, we need to do a
complete test. The status of each test is shown on the
Debug screen in verbose mode. Once variable RAM is
tested, SPRAM is tested (if available). The EEPROM is not
tested except for verification of the code download.
The I/O pin drivers are read back by the input register
to verify that each pin reads what it is set to in the OUTS
register. This is our loopback test. This is visually seen by a
pattern of ones and zeros also on the debug screen.
Finally, each pin is tested using an RCTIME test with
an external RC circuit. There are actually several ways a
pin can fail, and the last two tests are designed to catch
them all. This test ensures that each pin is within spec and
is fully connected externally to the module (no broken
traces or bad solder joints). The values for the RCTIME test
are shown on the debug screen, along with a pass/fail
indication.
During development of the code, I was trying to find
a clever way to determine if a BS2p40 was connected. I
had a few choices since there is no separate directive for
24- and 40-pin BS2p modules. I finally used the fact that
on 24-pin modules, the AUX pins are internally pulled up.
This is a reasonable method for determining whether we
have 16 or 32 I/O pins to test, and so the code can
reliably detect a BS2p40 and tests all 32 I/O pins.
Let the Testing Begin
Okay, let’s grab our module tester and drop in a
Stamp to test.
■ FIGURE 13. In the example, a BS2 was loaded onto
the tester. Notice the top LED lights. This is an indication
that the onboard regulator on the module is working.
The LED should light when the ZIF socket is closed. If we
now connect our serial cable or USB-to-RS-232, we can
download the test code and see what the status of this
module is.
