Advice on Logic Analyzer

I've never used a logic analyzer. A dual-trace digital scope and a little thinking is usually enough.

John

Strongly agree. "Little thinking" is the key part. BTW, I've never had any use of ICE for the same reason.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

I do use a hex background debugger (the PEMicro pod, for the 68332) when testing embedded code. It lets me load code into RAM (which will later be eprom), run it, step it, breakpoint, patch, snoop registers and ram. It also lets me directly thrash hardware interfaces. A combination of untested digital+analog hardware, untested FPGAs, and

4-12 kilobytes of untested uP code, running on a brand-new pc board, exceeds *my* ability to just think it through.

The bdm pod plugs into a little 10-pin header that we include on all of our embedded products.

John

"logicgeek" skrev i en meddelelse news: snipped-for-privacy@q10g2000prf.googlegroups.com...

No.

Check if the trigger logic can be programmed for what you need - for example if you are looking for memory corruption you want to trigger on access to the corrupted location which will be a sequence of adress words.

But hand-decoding an SPI data stream can get a little tiring. As the saying goes: been there, done that, skipped a bit - had to start over.

The OP might also want to look at the Ant8 and Ant18 analyzers from Rocky Logic

That said, I've been using one of the Intronix LogicPorts for years. Got it hooked up now watching a couple of CAN data streams, a 1 PPS time mark, a UART's TX & RX, and a half-dozen discrete I/O pins. Their latest firmware spin added the CAN interpreter to the existing SPI, I2C, and async serial interpreters. Makes it very easy to check a NMEA-to-CAN gateway.

--
Rich Webb     Norfolk, VA

You might just get a chance if you end up rolling your own PCI interface and having to debug it. :-)

Scopes can do that these days, though some require extra $ to unlock the feature in firmware.

Best regards, Spehro Pefhany

--
"it\'s the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Why would you do that in 2008?

Amen, brother.

John

There was a separate thread where he was discussing various ways of interfacing to the PCI bus and doing anything from rolling your own interface from scratch to using the simple/free PCI interfaces inside an FPGA to using a full-fledged interface (still in an FPGA) to using the, e.g., PLX interface ICs that do it all for you... hence I was just making the point that someone who did choose to go the "roll your own" route would probably end up using a logic analyzer, sooner or later, even though realistically I doubt John is going to go that route and agree with you that, these days, very few people could make a good case for doing so anyway.

Somewhat similar to spectrum analyzers these days where the basic performance isn't really that much better than those of a decade past but where you're paying to get a decoded trace of, e.g., a CDMA or WiMax RF sequence, a lot of the "value add" in a logic analyzer is now in the decoding provided as well. Even something as "simple" as USB is pretty difficult to "debug" on an oscilloscope due to the bit stuffing and error correction, yet all but the cheapest logic analyzers are fast enough (at least for full-speed USB @

12Mbps) to let your PC trivially do the decoding. (Of course there are specialized boxes/software just for USB decoding as well, and as I recall some are even

I've used the logic port. It has way to little memory and it is not very straightforward to use. If it where my money I would get the janatek because it has 1mbit/channel memory.

--
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Most of these PC based instruments are very poor to start with, after a few years they become unsupported and if you break them in the bin they go. You would do much better looking on ebay for an Agilent or Tek instrument for less money.

I usually don't make many mistakes of the sort that can be helped by an ICE. The ICE can be handy for troubleshooting of the minor technical problems... but the best cure is not to create those problems at first time.

Initially, I develop the flashloader with the basic diagnostic facility and the minimum hardware drivers for a new board. From there, the real development starts. I can output whatever parameters I need through whatever interface I have (Ethernet/CAN/RS232), without interferring with the real time flow of the program and the states of cache and SDRAM.

I could never understand why some people need to look at the SPI/I2C/UART/CAN lines when it is well known that the interface outputs exactly what you are writing into it and exactly in the way you configured it. The upper level protocol progress is better seen from the inside of the machine rather then by observing the lines.

I have to include the 14-pin JTAG connector, too, because some other developers just can't live without it :)

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Actually, there are bugs in some UARTs and similar bits of microcontroller hardware. Additionally, just because your code is good doesn't mean the code or hardware you're talking to is -- I've seen plenty of examples of bit-banged I2C code that violated the spec, and since usually the person who wrote the code isn't aware of the fact (or didn't bother to document it even if they did), the only way you'll find out exactly what's wrong is usually to probe the actual data lines.

Yes, once the lowest level interface is "trustworthy," I agree.

OK, just curious. I'm a bit naive; how does a logic analyzer handle the reflected wave switching thingy of PCI signals? Can it interpret the levels correctly?

I've experienced that too. It is a nice simple analyzer but if you want to do something a bit weird like sample an entire screenful of TTL RGBI (old video standard on 8 bit computers) data it cannot do this. With 2048 bytes per channel it can barely store one or two lines even with compression. It just doesn't work for this application. It does work great for looking at an entire scanline with state data from the rest of the computer. But I needed the whole screen full. Oh well, it's a good thing I stopped that project... :)

Does the LogicPort use transitional sampling? It appears to with a spec that that includes "compression": "Maximum sample compression: 2^33 to 1 (sample rates to 200MHz)"

If that is the case then the 2048 sample memory isn't as limiting as a normal time sampling 2048 sample logic analyser. But I'd go for the bigger memory unit myself.

Dave.

It can be a real help when, e.g., bringing up CAN on a new (to me) microcontroller family for the first time. CAN peripherals have wonderful "smarts" but getting there means a different register set for every manufacturer.

--
Rich Webb     Norfolk, VA

The few that I've used let you adjust the switching threshold to either any old voltage you liked or a handful of "common" standards. As such, they just don't "see" the incident wave and only transition low->high or vice versa on the reflected wave.

Truth be told, unless you're dealing with a physically large (long time delay) backplanes, often the incident/reflection "step" on the digital lines largely gets swallowed up by the slew rate and loading of the drivers anyway. On little 4-slot MicroATX motherboards, it can be hard to see the step! As far as I can tell, the big emphasis on, "PCI uses reflective wave switching!" wasn't so much because it was anything particular new or all that novel, but rather an indicator that someone had sat down and actually thought about the problem rather than just throwing something out there as many then-contemporary standards such as ISA and IDE had been done or using the brute-force high power/every line terminated/high-velocity-cooling-fan-included-with-purchase approach that minis and mainframes of the era were using.

---Joel