Debugging Busses

----------------

James Morrison asked about debugging serial busses like I2C, SPI, and
RS-232. Lots of people replied with suggestions:

Edward Gibbins wrote: Interestingly I am placing an order here:

http://www.pctestinstruments.com .

David Bevin sent: I don't think this answers James Morrison's
question but I remember using a HP 4952A Protocol Analyser for
monitoring and simulating RS232 comms. There's a picture of one here:
http://www.atecorp.com/Equipment/HP/4952A.asp

Harry Jones contributed: You could take a look at these tools:
http://www.mcc-us.com/I2C_Tools.htm .

Joy D. St. Amant suggested: A company named Willies Computer Software
makes serial communications tools. Check out there products at:
http://www.wcscnet.com/Default.htm . I have used their SI Scope; it is
a good product. I believe they have an upgrade to the basic product
which may be useful to Mr. Morrison.

Rijo Varkey uses Tracii http://www.telos.info/traciixl/ for I2C which
is a bit expensive and also TotalPhase's tools. Recently we came
across USB scopes but not used http://www.usbee.com/busbee.html. If
someone has already used this tool let know the feedback.

Greg Harris wrote: For I2C bus monitoring/debugging/testing I have
found the Corelis CAS-1000-I2C/E to be very useful. It is not cheap
(but they are having a 40% discount right now), but it is very
versatile.

Ray Keefe sent: One very inexpensive way to do I2C and SPI debug is
the RockyLogic ANT8. http://www.rockylogic.com/ It is the logic state
analyser which has direct decoding of both I2C and SPI. We have found
it to be easy and straightforward to use. So you can use it to monitor
the transactions provided they aren't really long.

You can purchase it from EasySync http://easysync-ltd.com/ although I
noted it is marked as discontinued.

RockyLogic also does the Ant18e which can debug address/data busses
and the like and provides faster sampling and a greater sample depth.
See http://www.rockylogic.com/products/ant18e.html

Bill Brasch had a suggestion: I recently came across this 8-bit USB
logic probe from Saleae that has I2C, SPI, RS-232 decoding. Low cost
$149. I have not personality used it, but it looks promising. Check it
out:
http://www.saleae.com/logic/fea...QObFQod5SV
..

Jay D. Hall uses:
http://www.microchip.com/stellent/...e=en028600
with great success. Hope it helps him!

Dave Clark wrote: The USBEE-AX and BX
(http://usbee.com/usbeeax-standardtestpod.aspx) is a brilliant tool
for analyzing USB and other serial protocols. We have the AX-Plus, but
the next one up the range seems to have an I2C controller as well. I
could not have even attempted a recent USB project without it. Imagine
sampling a 8 signals at 24MHz with 1,500,000,000 sample depth and then
decoding the result by hand? Colleagues have also used it for I2C as
well as other protocols.

For serial debugging, I use Telix, which has an excellent script
language which can be used to decode protocols (I have written scripts
for Multi-Drop Bus vending protocol and BACTA gaming protocols). The
scripts can also be used to simulate a slave or master device. It
appears to be a free download
(http://www.telix.com/delta/del...ndex.html) but I cannot be
sure of this. We purchased it about 10 years ago and have upgraded to
1.15D.

Christer Berg sent: You may want to look at Frontline's SerialTest

and other products from same company. Excellent decoding of most
industrial protocols.

Martin Zacho wrote: I would use a FPGA dev kit (from your preferred
manufacturer) and implement the relevant parts in it. The cost would
be below $100,- and some spare time ;-)

Bill Knight suggested: Have James Morrison check out RealTerm
http://realterm.sourceforge.net for debugging serial port busses.

Randy Glenn sent: In your most recent Embedded Muse, you passed on a
question from James Morrison regarding an inexpensive I2C / SPI / UART
debugging tool. The Microchip PICKIT2 programmer can handle all of the
above (to some extent, at least) and comes in at $35. It can even act
as a 3-channel 1MHz logic analyzer - not great, but still not bad for
$35. Oh, and it programs and does ICD for microcontrollers, too. More
info at http://www.microchip.com/pickit2.

I should probably also include a link to the PICKIT 2 Serial

Analyzer page,
http://www.microchip.com/stellent/...e=en028600,
where the firmware and software to do the I2C and SPI stuff lives.

Ben Sweet contributed: Regarding James Morrison's question about
debugging network interfaces. He might consider the Netway tool from
Smart Engineering Tools, Inc.: http://www.smtools.com/

Paul Carpenter wrote: I have never really come across a completely
multifunction device for doing insertion of commands and for most
systems (I2C and SPI like) the hardware alone dictates, that adding
another master device will require changes to hardware or jumpering
out the bus to go via your pseudo master. Back to the problems of two
drivers at same time on an SPI bus is a hardware issue, and blowing
devices. In many cases you would have to have a device to pass all
traffic, add extra, or takeover the bus.

However for monitoring many digital scopes these days have the
ability to do the monitoring. The problem of course is in the matching
with SPI the clock and data phases, along with maximum data rate.

I am reminded of something I did in a PLD the other year for testing
ASICs, device being tested was its own I2C master, to continuously
communicate with an I2C EEPROM containing calibration data. However I
quickly discovered the amount of reads and writes required to test
about 500 ASICs would exceed the EEPROM write cycles spec. Also the
data sets that had to be stored in the EEPROM for device testing was
in fact very simple (bit manipulation algorithms from the address and
mode), some places were just binary inversions of symmetrical places,
and some parts had to be read/write registers. By creating an SPI
register in a PLD, I was able to compress all the function control to
be configured for another block of the PLD to then operate as a
simulator of the I2C EEPROM. This included encoded bits in the control
register to ensure the next access would deliberately contain bit
errors to force error conditions as part of the test process.

One advantage of this was that alongside digital scope measurement of
the signals to check frequency, levels etc.. we could determine if the
ASIC was in a fault condition and driving the I2C bus at about 2 MHz,
which the emulator happily coped with

Considering the various speeds, clock relationships, let alone data
protocols need to operate, especially serial memory devices. It may be
easier to derive a mixture of scope and PLD/FPGA that suits your
application each time.