Advice requested on AVR debugging tools

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

I am interested in the Arrow Electronics promo offer of an AVR JTAGICE mkII for $149. Hopefully this special promotion is still available (mid-May 2010) even if there is a one or two month waiting period.

I'd like to know if there are any emphatic positive or negative opinions among the users here of this product.

I have had an ICE200 in the past and found it invaluable for developing complex (at least for me) programs. But the light fragile flex-cables on my ICE200 broke. I also burned out several pins by accidentally outputting logic high to pins that were jumped to ground on the prototyping breadboard.

Having the ICE200 model obsolete devices is an annoyance, but not a real problem because the AVR core is basically unchanged since the 90S1200. What left my head spinning about the ICE200 was having no documentation on the error numbers and messages. I had no idea what caused them or how to fix them. But that's a common problem across the industry.

The great thing about the ICE200 is being able to make hundreds of small changes in the code and breakpoint matrix daily without 'wearing out' the base AVR (since there is no real microcontroller actually in the circuit).

I'm really unclear about whether JTAG 'wears out' the underlying device. Are breakpoints done by writing a special op-code directly to the flash memory? Or does each program address have a breakpoint bit that is monitored by the internal JTAG circuitry?

What is the main advantage of using JTAG over debugWire? Is the Dragon still prone to self-destruct without warning? (I've had two, and neither one lasted more than a month. I've used a case for the Dragon PCB and a powered-USB hub, with no luck). Will Atmel repair the JTAGICE mkII if it just fails without warning or reason? Does that happen often with this product?

All opinions, reasoned or extreme, are welcome.

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

Quote:

I'm really unclear about whether JTAG 'wears out' the underlying device. Are breakpoints done by writing a special op-code directly to the flash memory? Or does each program address have a breakpoint bit that is monitored by the internal JTAG circuitry?

What is the main advantage of using JTAG over debugWire? Is the Dragon still prone to self-destruct without warning? (I've had two, and neither one lasted more than a month. I've used a case for the Dragon PCB and a powered-USB hub, with no luck). Will Atmel repair the JTAGICE mkII if it just fails without warning or reason? Does that happen often with this product?


JTAG breakpoints usually use on chip address comparators within the OCD unit so on the whole, no, they don't "wear out" the chip. However I think it's the mega128 that is a special case (read JTAGICEmkII manual) and there's some limit on the number of breakpoints before it starts replacing opcodes in flash with BREAK which actually involves reprogramming the AVR and hence will "wear it out".

One of the prices you pay for using debugWire is that it ALWAYS rerograms flash to insert BREAK opcodes so there you will have to worry about the life of the AVR.

As it says in the manual (maybe Dragon not ICEmkII?) you should not use your "development chip" in production in case it has been worn out by repeated code download and BREAK insertion.

Another issue is that when you do "start debugging" then (unless you have switched it off in one of the config menus) the code flash will always be erased and reprogrammed with a new code image and this, in itself, will also wear the chip.

In use there's not a lot to call between JTAG or dW. I'm just as happy using a Dragon or ICEmkII with dW to a mega168 as using JTAG to a mega16 - you wouldn't really know that a different form of interface was being used apart from the time you come to switch DWEN in a mega168 off which can be a bit "fraught").

It seems that the latest Dragons (the ones with four PCB mounting holes) are far less susceptible to USB-PSU damage than the first issue.

Cliff

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

IRC there is 4 hardware breakpoint available in modern AVRs. One of'em will be consumed more or less immediately for single stepping, so you have three left. IIRC, when you place a fourth one it will be a soft b reakpoint, and I think that this is done by reprogramming the instruction at the desired address with a BREAK instruction. When the execution hits that point the original instruction is written back and executed and then the BREAK instruction is writtenb onto place again.

Now don't take my word on this. This is merely how I recall it. I am however sure of having seen a warning from AVR Studio when trying to place a fourth breakpoint.

(All based on stuff done more than a year ago, with the AVR Dragon.)

Still, the flash has an endurance that is nominally 10K writes (or has that been upped to 100K now?). You can play around quite extensively before hitting that limit, and for developing having to replace the AVR from time to time should be no great financial burden.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Ah now you've refreshed my memory. It's true there are usually 4 address comparators so 4 hardware BPs but one used by single stepping, soft BREAKs once all the h/w ones are used. The mega128[A] exception is that it ONLY supports soft BREAKs. So it will have similar flash wear to a debugWire chip.

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

So the debugWire does not support "hard breaks"?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

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

Quote:
What is the main advantage of using JTAG over debugWire?
You cannot choose, you must use whichever the chip comes with.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

clawson wrote:
Ah now you've refreshed my memory. It's true there are usually 4 address comparators so 4 hardware BPs but one used by single stepping, soft BREAKs once all the h/w ones are used. The mega128[A] exception is that it ONLY supports soft BREAKs. So it will have similar flash wear to a debugWire chip.

I think that's actually backwards: The ATmega128[A] has a buggy implementation of the BREAK instruction, so it ONLY supports the 4 hardware breakpoints.

JohanEkdahl wrote:
So the debugWire does not support "hard breaks"?

Nope. debugWire doesn't use hardware breakpoints at all.