Debugging tools, what would you like?

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you could have a tool or tools for debugging embedded hardware/firmware what would that tool or tools be?

Just to put this in context, I'm playing with some ideas for a new debugging tool, think logic-analyser-slash-protocol-analyser-slash-monitor etc. We're not talking big $ here (maybe $100-200) so as much as I think a 3GHz storage scope would useful that won't be in the design.

For example some things I have in mind are timers to measure interrupt latency, simple low-footprint IO for the target processor, 1 channel scope, 8 channel LA, SPI/I2C/UART/etc protocol analyser etc.

Any ideas?

Are there already enough such tools around?

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Microchip PICkit 2 programmer/debugger does something like that. Someone has written software for it for programming AVRs.

Leon Heller G1HSM

Last Edited: Wed. Oct 12, 2011 - 08:56 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't see that they have any storage/analysis though. I'm thinking simultaneous recording of serial, digital and analog with complex triggers plus things like (with a little help from the target) timing interrupt latency, ISR execution time, number of iterations through a loop etc. All with min/max/avg.

AFAIK there's nothing that does this but maybe that's because nobody wants it :)

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is rather limited.

You will have a problem in that Atmel hasn't released the necessary information for implementing a debugger for many of the current chips. As for the other functions, there are low-cost FPGA-based logic analysers.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
there are low-cost FPGA-based logic analysers.

Yep, that's one reason I posted because there are many such beasts around.

I still don't think there's any that do what I'm proposing, for example trigger if a loop inside an ISR iterates more than 5 times, or maybe just record the average number of times it does iterate. Or trigger if you see "Hello" on a UART line after seeing "world" on the SPI while a voltage at another point is > 2.5v.

You can't to that with serial decoders in post processing, which I think is how all the existing (the cheaper ones anyway) gadgets work.

OK that's a bit of a stretch and maybe just too esoteric for most people and applications.

But I would think that, for example, when stress testing a new device the ability to leave the DUT running for two days and trigger if an ISR ever took too long to execute would be useful.

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For digital work, check out Saleae Logic. It is a USB logic analyzer that streams 8 (or the bigger model 16) channels of digital data to your PC for later analysis. Speed should go up to 24MHz, but longer captures at that speed require faster PCs than I have, 8MHz has been enough for me. When a capture (limited by about your PCs memory) is complete, you can add different analyzers like I2C, SPI or whatever. In Linux there seems to be a bit more than 1Gbyte limit for a process to use memory, which is good for streaming more than 125 seconds of data-logging at 8MHz.

Then, another PC logic analyzer is the Intronix Logicport, has 32 channels and up to 500MHz capture, but it captures things into its internal 2kbit per-channel memory before transferring that memory buffer to PC so while you can see very fast signals and a lot of channels you can only see the last 2048 transitions on a screen, so it cannot be used as a multi-second streaming datalogger.

For any serious bus specific work, TotalPhase makes SPI/I2C specific devices (analyzers like Beagle or host/slave like Aardvark). The analyzer streams any captured I2C/SPI data to PC screen in live for you to see directly as bytes in packets, not signal waveforms, although some bit/packet timing data is available. It means it will fit 60 minutes of continuous 400kHz I2C bus logging into tiny amount of 200 megabytes or so, but it cannot be used as a general purpose logic analyzer.

Seriously are even the real logic analyzers able to count to 5 before triggering (not much experience with those)? First of all you would need to generate a signal which means when you are in the interrupt, and at least the pulses for the iteration count. So the code might as well be the one that generates a pulse on GPIO if it ever reaches some iteration count. Then again the code knows that so it can set a flag or LED indefinitely on or signal that through serial port that it has been over its limits. But for a GPIO signal that gets set after entering an ISR and gets cleared before exiting an ISR, that timing and its violations are easy to measure with almost any kind of LA/scope, just set it to trigger if pulse is longer than time you want.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
1 channel scope

I often use two channels.

Frequently I need to see how the timing of two signals occurs and interact.

I might also trigger one channel on the Main Loop, and the other channel on an ISR. Easy to see the % of processing time spent on the ISR(s).

Of course I'm still stuck in the dark ages, primarily debugging with an LED and an LCD; and an O'scope occassionally.

I did break down an purchase an (inexpensive) IKA Logic logic analyser when I was writing an Xmega PDI programmer. I think that was about the only time I've ever used one.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
For any serious bus specific work, TotalPhase makes SPI/I2C specific devices

I wasn't aware of them, ~$450 for a device that only does one protocol is a bit steep though. I'm thinking <$200 for a gadget that will do multiple protocols plus scope and LA as well (all simultaneously).

Quote:
First of all you would need to generate a signal

Correct, that's what I currently do with a 1-line macro that's just two instructions and therefore almost no overhead to the target code. If you start adding counters and conditional code that you are intruding more on the application.

Quote:
that timing and its violations are easy to measure with almost any kind of LA/scope, just set it to trigger if pulse is longer than time you want.

AFAIK the cheap analyzers can't trigger on timed events.

Quote:
When a capture (limited by about your PCs memory) is complete, you can add different analyzers

True, but it can't trigger on serial events, it's all done in post-processing.

Quote:
are even the real logic analyzers able to count to 5 before triggering

Most good LAs allow up to 4 states in a trigger from what I've seen. Good for most things but not for mixed signal triggering I think.

Quote:
I often use two channels.
Frequently I need to see how the timing of two signals occurs and interact.

But do you need analog for that. I do the same now but I only need to measure digital signals.

Jepeal, I currently use a Salaea and do all you are suggesting, it's a great tool and I'm well happy with it. I'm thinking of a tool that does that and many other things. The pulse counting I gave as an example is a small % of the functionality I have in mind.

For example average interrupt latency or min/max frame lengths on an RS485 bus, is there any way to measure that sort of thing with current tools?

I really appreciate your input guys, and if the result of feedback is that it's not worth the effort because people are happy doing what they are currently doing then that's a valid outcome as well.

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rob,

I assume you have seen this DSO Quad-Pocket-Sized Digital O'scope on the Spark Fun site. It may act as a reference point as you consider processor speed, display, etc. It has an Arm M3 and a FPGA and gives the user 4 channels at 72 MSamples/Sec. SFE's price is $225 USD.

(I don't own one, I just saw it as not too different from what you have been describing.)

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes I am aware of that, very neat unit, I would never be able to produce such a nice package, but should be able to have a lot more features. I had forgotten about it though and funnily enough have a working name for my gadget of QUADD (Quite Useful All-purpose Debugging Device), I may have to rethink that :)

As it happens my current design also has an M3 (LPC178x) and FPGA (Spartan 3E). I was planning to use a touch screen and local display but I think it's too limiting and probably doubles the price. So i've been learning Qt so I can write a cross-platform client app.

______
Rob

Scattered showers my arse -- Noah, 2348BC.
Rob Gray, old fart, nature photographer, embedded hardware/software designer, and serial motorhome builder, www.robgray.com