The perfect debugging tool

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

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

I've already included a lot of stuff but don't want to bias any opinions so won't reveal all just yet.

And before you ask, yes it will be open source, so your ideas won't become proprietary and make me a million at your expense :slight_smile:

So, bright ideas anyone?


Rob

Sniffer for serial, i2C, SPI, onewire, ...
RAM usage monitoring ...

Turn the Open Bench Logic Sniffer into a shield

Ability to interpret commands to and responses from slaves.
A lot of the time, simple serial prints are all that is needed, but being able to see the hardware bits flipping is sure handy at times :slight_smile:

Think a tri-state/input mode test would be handy? Maybe pull a pin high/low with something like 0.5mA load, if it can wiggle it is not active output?
How much can a pullup resistor source?

Sniffer for serial, i2C, SPI, onewire,

Already done, 4x serial signals, 1xi2c and 2xSPI, all in hardware. 1-wire not done because that's a software thing, therefore it can be done later.

RAM usage monitoring ...

Very intrusive, but could be done. I know this is a common issue. The monitor could fill blank RAM then test for the pattern later, finding the bottom of the stack is easy and AVRmon already does that, I just have to find out where the top of the heap is, maybe a quick 1-byte malloc.

Turn the Open Bench Logic Sniffer into a shield

Done, the plan is to make it a shield with all connections (except some user inputs) pre-wired.

Ability to interpret commands to and responses from slaves.

My AVRmon program already does that, I plan to incorporate it into this gadget.

A lot of the time, simple serial prints are all that is needed,

Handled in a couple of ways, you won't need the Arduino's hardware UART to print data to the screen.

being able to see the hardware bits flipping is sure handy at times

Done.

a tri-state/input mode test would be handy? Maybe pull a pin high/low with something like 0.5mA load, if it can wiggle it is not active output?

Hmm, I hadn't thought of that. I'll do so now :slight_smile:

Thanks guys, it sounds like I'm on the right track so far.


Rob

Here's a block diagram, of course block diagrams are easy to draw :), getting a working circuit and code is a totally different thing.

How about a FT2232H based JTAG debugger?

That FT2232H does look like one sweat chip.

I already have USB, but no JTAG for two reasons. The first is that I don't know much about JTAG, the second is that most Arduinos don't have JTAG.

The Mega does though and the pins are brought out to headers.

I'm happy to collaborate on this or any other feature.


Rob

Graynomad:
most Arduinos don't have JTAG.

oops, my bad, I assumed all AVR chips had JTAG, I guess not
I wonder if you can get DebugWIRE working somehow without official Atmel hardware

I wonder if you can get DebugWIRE working somehow without official Atmel hardware

Now that would be nice, why it's a closed protocol I have no idea.

I suppose it could be broken but I've not heard of it being done yet, there's an opportunity for a bright young lad.


Rob

Looks like you are only planning to support standard 168/328s with 20 IO?

324/644/1284's have JTAG too, and dual serial. I need to come up with neat project for my Bobuino.

That drawing is a little bit out of date (3-4 hours :)), at last count I had all 20 standard IO plus another 8 "user" inputs making a total of 28 that feed directly into the analyser. I think you have 32 IO on the Bobduino so that's close. So far that's all I can pack in (at least for high-speed sampling) as I only have 32 bits and some are needed for housekeeping. I can however add extra bits for low frequency (still maybe a few MHz) checking of logic levels.

All could be displayed at human-speeds, maybe a nice graphic with LEDs for each pin. Actually, although a GUI is a way down down the track maybe having a picture of an Arduino with "logic probes" and "volt meters" you attach to pins would be a fun exercise.

As I said, if someone knows about JTAG I'm happy to collaborate, maybe the best thing to do is just allow a convenient way to connect a standard JTAG debugger. OTOH maybe it's not that hard to implement JTAG myself, I just don't know :frowning:

I have 4 serial inputs, by "inputs" I mean single signals, therefore that's two full serial lines, 4 half lines or any combination. These go into hardware UARTs for protocol analysis but any of the 8 user inputs can to timing as well. If an analyser is written to decode timing waveforms like the Saleae et al then you can presumably have as many as you like.

The monitor program is table-driven and can easily be made to work with the 1284.

As the Bobduino has standard headers this should plug straight in. The extra 8 IOs on that expansion header could be cabled to my user inputs.

BTW, I've added your "pin test" idea.


Rob

The four serial inputs could be 2 sets of Rx/Tx pins? Thats cool then.

The pin test, guess it could be handy.

I don't know anything about JTAG except the names of the signal lines - TDI, TDO, TMS, TCK - and what its supposed to allow you to do per some Atmel website reading. I haven't done anything fancy enough in SW to need more then the occasional serial print tho.

The four serial inputs could be 2 sets of Rx/Tx pins?

That's right.

I'll build pin testing into the logic probe I think.


Rob

floating test in a probe - that sounds good.

Attached is the current ideas document (including up to date block diagram), I think I've covered what's been mentioned.

I've actually done an initial PCB placement and most of the schematic design for the front end, just need to hook it all up to the controlling micro (a non-trivial task, any LPC ARM experts out there?).


Rob

quadd_specs.pdf (60.9 KB)

Never worked with an LPC ARM but happy to do some code review

Will it be the MBED processor ? Its is on my ToLearn list

IDE over the web (co-editing?)

"Oscilloscope
• 6-channels connected to Arduino analogue pins
• 12-bit sampling up to 400kHz (1ch) less for multiple channels"

Is that fast enough to look at something like I2C and determine that smaller pullup resistors are needed?
Just an example as that's one of the last things I had happened to look at.

Logic analyzer - will that use the system's 8 or 16 MHz clock as the sampling rate clock? Or an independent source from the LPC ARM?

Never worked with an LPC ARM but happy to do some code review

Thanks, I haven't either but it just seemed like the right chip and it's something I've wanted to use for a while now.

Will it be the MBED processor ?

No, I just can't get my head around that IDE over the web thing, having to be connected to do development just doesn't make sense to me. The Mbed uses a 1768 which is very similar to the 178x I plan to use, so close in fact that I thought I would use the Mbed to prototype code, but then there's that "IDE over the web thing" and as far as I can see there's no provision for doing it any other way.

However if you want to get into them and also want to contribute to this I see no reason code can't be easily ported to/from the Mbed and the 178x.

I might get a couple of LPC Xpresso dev boards. They are only $30 and you get the free IDE (a real IDE based on Eclipse). I've already downloaded the IDE and played with some sample code, it works great.

Is that fast enough to look at something like I2C and determine that smaller pullup resistors are needed?

Hmm, generally I'd say no as the 400kHz sample rate is the same as the typical i2c bit rate and with analogue sampling you typically want to sample at about 10x the frequency of the data you are sampling.

However, doing this might work as you really aren't interested in the waveform per se, just whether or not the signal is being pulled low enough. So if the samples were taken at the right moment the viewed waveform would probably look like some form of triangle wave but the highs and lows should be the voltage on the line at that time.

So the short answer is that it should work in a fashion.

The 400kHz is the max rate the chip can read, so there's not much to be done about that without an external ADC feeding into the digital channels.

Logic analyzer - will that use the system's 8 or 16 MHz clock as the sampling rate clock? Or an independent source from the LPC ARM?

Currently I plan for the sampling to be run with an internal clock (timing mode), as to how fast I don't know yet but 20-40MHz should be doable (all I can work on is the data sheet at present, I have no experience with these chips). It may also be possible to use an external clock (state mode), I'll look into it.


Rob