Advice on HW Selection (Debug)

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

Background:

I design and program boards built around a variety of AVR chips, mainly the 168/328, 1281, and 128RFR2 (and RFA1). I only use SMT parts, and do not pre-program the chips before assembly.

I have used an AVRISP mkII exclusively to program all of my AVR projects. This means I always include a 6 pin ISP connector in the design (segue: this product, http://www.tag-connect.com/TC2030-IDC is great for reducing programming header size and height. It easily replaces the stock cable in an AVRISP mkii).

For debugging, I use either an LED or a spare UART port.

However, I have several designs coming up that will require two UARTS for normal operation, making any potential debugging much more complicated. As such, I am looking to purchase a debugger (prepare for more questions to follow, as I have never used a debugger before)...

I am not sure what to buy. Keep in mind, this will likely be for programming in-system and/or debugging. I will not be doing any high-voltage programming.

I have looked at both the Dragon and the AVR JTAGICE mkII. I like the price point of the Dragon better, but have ready MANY posts (here and elsewhere) about how easily they are damaged/fried. The device I am buying will likely see heavy use as a daily workhorse for programming and debugging. While the sticker price of the JTAGICE seems a little high, I would be willing to pay it for increased reliability/durability.

Can users of either/both provide recommendations?

Edit: After frantically copying the above text (after hitting the submit button and waiting an interminable amount of time), I was surprised that when this did eventually post, it didn't have a captcha.

Science is not consensus. Science is numbers.

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

Quote:
I have never used a debugger before
Have you ever used the simulator in Studio? Then you know how to use a hardware debugger.

If you are using AS6.x (my condolences... :? ) then get a JTAG Mk3, otherwise a JTAG Mk2 works well with AS4 (dearer than a MK3 unless you can get an unwanted unit). The Dragon works well but not as tough despite the name.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

If you use it professionally I would almost say just get the JTAG ICE. as robustness is a key parameter then.
I do not know though how robust the dragon can be made. 'Plons' has made a nice dragons shield and as far as I have followed the threads using that will make it very robust. In other words I have not yet seen a post on killed dragons when they had a shield mounted. So you might also go for that and have another project to do before actually starting using it.

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

Quote:
mainly the 168/328, 1281, and 128RFR2 (and RFA1)

I do not know the tinys but for JTAGed devices you only need to connect GND,TCK,TDO,TDI and TMS (5 wires). And perhaps Vdd if you want to have an automatic threshold applied to 1.8V and 5V targets. But if you want that Vdd to be set manually then you could use GND, nRESET, TCK, TDO, TDI and TMS and then you do not have to mount reset push-button on your board (saves space).

And about buying an AVR debugger - just keep away from ARM Cortex-M and you can be satisfied with any Mk53. Unfortunately I have made that silly mistake and now I feel a disgust whenever I touch those AVRs.

No RSTDISBL, no fun!

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

hobbss,

I always rely heavily on my serial debug port in most of my micro-based projects. I always make sure I have a dedicated debug serial port, even if I have to go to a larger micro to do so. There are certain AtMegas that have 4 UARTS, and I think this is more common in the XMega line.

In one or two cases I was forced to use the SPI port as my debug serial port. I routed the SPI bus to an external AtMega which converted the SPI characters to "RS-232" characters which were sent out this external AtMega's uart to my HyperTerminal or TeraTerminal console.

One way or qnother I make sure I have my debug port! Frankly,I wouldn't know how to develop annd debug a program without one.

In the past I have used many types of in-circuit emulators as well as the on-chip emulators we have in today's breed of processors. IMHO these serve well as "fine tooth" debugging tools, whereas my serial port is a "broad brush" tool which I can easily tailor to many different situations.

My need for the fine-tooth capabilities provided by the emulators fell off dramaticly when I switched from assembler to C-language programming. I don't think there's been a self-inflicted problem in years I haven't been able to unravel and solve with my serial port bag of tricks.

Also, since I do a lot of off-site work, I have found that the debug port stream constantly emitted by my programs can be easily captured in a textual log file and emailed to me by low-skill individuals (e.g. Project Managers). If I can't identify the problem from the log file, it just means my debug printout is not complete enough and I expand its scope!

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

Thanks for the thoughtful replies.

John:

I have not used the simulator in studio. Most of my complex code involves talking to peripherals, so I have not even tried using the simulator. I am a full-blooded convert to AS6.1 (I recently went back to an old project in AVS4.18, and sorely missed a lot of the features from 6.1). I was unaware that there was a mark3 JTAGICE - that's what I get for relying on three year old threads on this site. It looks like a mk3 is a quarter the price of a mk2.

Meslomp: this is for professional use. Thank you for your input - it agrees w/ the statements of others w/ regards to the viability of the Dragon under everyday use conditions.

Brutte: I'm not sure I follow you w/ regards to the Mk53. In any event, aren't the JTAGICE devices only for AVR8 and AVR32 chips anyhow (i.e., no ARM)?

Chuck: It sounds like your MCU development procedure is similar to mine - even down to having other people send you text log files of the serial output. However, I am locked into my current AVR, because size and power are very important (and the ATMEGA128RFR2 is the only wireless AVR SoC available).
If I were to switch to an Xmega (are there any Xmega transceiver/mcu SoC?), it would be a completely new design rather than a respin w/ a new peripheral.

Science is not consensus. Science is numbers.

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

Quote:

I have looked at both the Dragon and the AVR JTAGICE mkII.

Then you have made a mistake. ICEmkII was the old model. The ICE3 is better in every way. Much faster but also cheaper. The only downside is that it was not supported in AS6 but now that AS6 has stabilized (well almost!) then there's no reason to avoid considering it. You will notice that ICEmkII has been priced to be unattractive. Your choices really are $50 for a Dragon or $100 for an ICE3. Given that the latter is a more "robust" design (in every sense of the word!) then unless your budget is really tight it's a far better buy than Dragon.
Quote:

In any event, aren't the JTAGICE devices only for AVR8 and AVR32 chips anyhow (i.e., no ARM)?

Not since 6.1. In the most recent release Atmel added (tentative!) SAMD20 support to the ICE. Expect it to get better and cover more Cortex in future releases.

(then again most Cortex boards have a debugger already on the board so the need for a separate interface is not so strong - and you get the board+debugger for $40 which is even less than even a Dragon costs - the joy of Cortex!)

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

hobbss,

I see your situation. Well, you might give some thought to my "SPI UART" method.

First, set-up an external AtMega as an SPI Slave and wire it to your SPI port on your main processor. Use both MOSI and MISO - MOSI is transmit out, MISO is receive in.

Second, rewrite your putchar and getchar routines in your main processor to use the SPI transceiver.

Third, write a simple SPI to UART conversion routine for the external AtMegaxxx that simply passes every byte it receives from the master to its own UART xmit-out, and every char it receives from its UART receive-in to it the SPI slave's output holding register (the master must query this peridiodically to get the slave's "characters").

On this last point of receiving characters from the SPI slave. Typically, in my applications my ratio of output characters ( i.e. putchar invocations, most often via printf statements) to input characters (i.e. via getchar) is about 1,000,000 to 1. So, I would usually use a simple polling routine for taking SPI input "characters" from the slave. Of course, you could run an interupt-driven buffer scheme if you expected higher "receive" character traffic.

The SPI-UART hardware is extremely simple: AtMegaWhatever (in my case an AtMega168), crystal oscillator, and a USB-TTL-to-Serial adaptor to interface to Hyperterminal or TeraTerm. At low baudrates you might get along with the AtMega's internal oscillator and loose the xtal osc. Because of the USB-to-Serial converter cable you don't need the old-school MAX232 chips either to talk to a PC.

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

Just for clarification: the Jtagice mk3 IS supported w/ AS 6.1?

@Chuck: I got interrupted when typing my previous response, and forgot to finish it. I intended to say I was intrigued by your SPI-UART conversion. I think that I may, in fact use that in this design. I am already using the SPI bus for something else, but I have a spare pin available to use as a second SS. I have enough old boards lying around w/ megas and MAX3250's -- I think I even have one w/ the SPI pins pulled out to a header...

Science is not consensus. Science is numbers.

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

Quote:

Just for clarification: the Jtagice mk3 IS supported w/ AS 6.1?

Yes but you may find if you use 6.1.2730 you have to roll it back to a previous f/w version (see many posts about this in the AS6 forum). This doesn't just apply to ICE3 though - it may be necessary for other tools too.

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

Quote:
I have not used the simulator in studio
How about a monitor program running inside the micro?
I guess if you are a young person you won't know what I'm talking about ... :-)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

hobbss,

I've pulled the SPI/UART trick in a few programs where the SPI bus had several peripherals. If they are occasionally used it not so bad, but if you have high SPI traffic, it can be problematic (but not unsolvable).

In one case I used the I2C (TWI) bus instead of the SPI bus (I2C-to-UART), but that was a bit more difficult to get working because of the inherent complexity of I2C.

I should also tell you about another UART debug technique I use pretty often. (Maybe you already know this.) Instead of sending printf's directly to the UART (via putchar). I send all putchar-output characters (including CR & LF) to a RAM-FIFO-buffer. Then, using a periodic timer (sometimes interrupt driven, sometimes just a main-loop counter), I pull a single character out of the FIFO and write it to the UART. The affect on the terminal screen is that of a Teletype with a character rate of 10, or so, characters per second (depends on your output timer rate). I refer to this technique as "Ticker Tape" mode debugging.

I use this in programs which are very time-restricted. The printfs get pumped into the FIFO buffer at a very high speed because putchar is not wating for the UART to empty between characters. The main key to implementing this scheme is to modify purchar to write to the FIFO-buffer instead of the UART. And, of course, you have to balance the buffer size against the typical number of characters you are pumping into the buffer ( via putchar ) per unit of time, against the rate at which you are xmitting htem form the other end of hte buffer. (I usually include an overflow flag with the FIFO management routines, and send a special character to the UART to denote an overflow condition. If that character shows up in the output stream, I simply trim back (i.e. comment out)the number of printf's per second )

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

Chuck - those are some good techniques. Because I only have one device currently on the SPI bus, I will probably stick to that. On the other hand, the I2C would not be too difficult, as I already have some code written to use that peripheral in the MCU.

I have a lot of dead time in the program right now -- running on a 10ms tick, where tasks take less than 1ms.

Science is not consensus. Science is numbers.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
#include "stm32l1xx.h"
#include 

int
main(void){
	FILE* fh;
	fh=fopen("d:/Documents/semihosting.txt","w");
	fprintf(fh,"Hello ARM Cortex-M3 World!");
	fclose(fh);

		while(1){
		}

return 0;
}

Attachment(s): 

No RSTDISBL, no fun!

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

Um.... what?

Science is not consensus. Science is numbers.

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

Brutte is simply showing that the ARM can send debug information transparently.

In theory, the AVR's JTAG can 'almost' do this. Unfortunately, it is never implemented properly.

Just have a look at the debug features that are available on a humble Cortex-M0+ chip. Your app runs at full speed and the debugger is updating memory / registers in real time.

Compare this with debugging an Xmega !

David.

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

I am an utter tyro when it comes to using debuggers. I am considering getting a JTAGICE mk3 and looking for some good tutorials.

Science is not consensus. Science is numbers.

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

AFIK, the JTAGICE-3 can only do AVR32 and AVR.

I have no idea how 'clever' the AVR32's JTAG is.

Quite honestly, you can get on pretty well with the traditional "run to breakpoint and download data"

Mind you, you can get on quite well with regular printf()

Watching an ARM program run at full speed and update memory windows, registers, logic analyser displays, ... is very impressive. Just follow the Keil tutorials with a $15 Kinetis or $12 STM32 board. They even come with their own on-board debugger systems.

I presume that Atmel's SAM4S Xplained will be able to do all this via its on-board J-Link debugger. OTOH, I doubt if Studio could ever compete with Keil when it comes to actually use it to its full extent.

David.

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

Quote:

and looking for some good tutorials.

It's called the Simulator.

If you have ever used the simulator in AS4 or AS6 you already know exactly how to operate any debugger you might buy. All the operations you are used to: breakpoints, single stepping, watching variables, modifying IO registers, etc. should work just the same(*) with a real AVR+debug interface as they have been doing for you in the simulator.

If you haven't used the simulator then now may be the time to explore as it will prepare you for what's to come.

(*) well it should be "just the same" but the simulated AVR is not 100% perfect (and has no simulation of external activity) so what changes when you use OCD is that it's just a more accurate representation of real world operation.

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

Starting with the simulator would be a good place to start.

I have not used it to this point, because most of my designs have many external peripherals. Without them, simulating the system behavior becomes slightly difficult.

Science is not consensus. Science is numbers.

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

Then for the purposes of learning just throw together something simple. You could run some "internally hosted" operation like JPEG decode (for example) where nothing in the code actually cares what happens in the real world. Or you could just do a simple IO program like something that flashes an LED and simply observe the PORTx "blobs" in the simulators I/O display to see them changing state (try for the classic KnightRider/Cylon Eyes effect perhaps?). Or if you were feeling really brave you could explore the 6.1 simulators recently added "Stimuli" feature (something that finally got ported from the AS4.18/4.19 simulator to AS6). That is documented here:

http://www.atmel.no/webdoc/simul...

But I think I'd just try the Cylon thing first ;-)

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

Quote:
Starting with the simulator would be a good place to start.

The uVision has a 32kB-limited free ARM simulator which does support peripherals. There is a selection of stuff to pick from (some peripherals even come with GUI), scripting etc.
And for the most demanding users they offer API and documentation for dlls so now you can include your whole quadcopter in that simulation.

No RSTDISBL, no fun!