My JTAG Cable1 has just failed and I need to get another JTAG programmer, 
ideally with a USB interface although if it has to be serial so be it. 
Obviously I'd get an Atmel JTAG ICE Mk11 if the cost wasn't so ridiculously 
high so it'll have to be an alternative.

What are people's views on the best one available at the moment?

Thanks.

Roger. 

> My JTAG Cable1 has just failed and I need to get another JTAG programmer,
> ideally with a USB interface although if it has to be serial so be it.
> Obviously I'd get an Atmel JTAG ICE Mk11 if the cost wasn't so ridiculously
> high so it'll have to be an alternative.
>
> What are people's views on the best one available at the moment?

I bought the Olimex USB JTAG. It is really a serial JTAG with a
USB-serial adapter inside it, of course. It is cheap, it works exactly
like a regular JTAG-ICE (mk.1), I can't fault it. However you should
note that the documentation is not exactly right, and there are some
things I don't completely understand:

* adapter is target-powered despite being described as "USB-powered".
* you MUST have Vref connected on the JTAG interface, and it must be
connected to some nonzero voltage on your target.

>However you should note that the documentation is not exactly right, and there
>are some things I don't completely understand:
>
>* adapter is target-powered despite being described as "USB-powered".
>* you MUST have Vref connected on the JTAG interface, and it must be
>connected to some nonzero voltage on your target.

our AVR-USB-JTAG have opto-isolatation between USB and target, this is
why you have to feed power from target too :)

the good news is that this way you can debug safely targets which are
running on 220VAC


Best regards
Tsvetan
---
PCB prototypes for $26 at http://run.to/pcb (http://www.olimex.com/pcb)
PCB any volume assembly (http://www.olimex.com/pcb/protoa.html)
Development boards for ARM, AVR, PIC, MAXQ2000 and MSP430
(http://www.olimex.com/dev)

t...@my-deja.com wrote:
> >However you should note that the documentation is not exactly right, and there
> >are some things I don't completely understand:
>
> our AVR-USB-JTAG have opto-isolatation between USB and target, this is
> why you have to feed power from target too :)

Right, I do understand this - but the documentation is a little bit
confusing.

I think it says that both pins 7 and 4 need to be connected to the same 
voltage but I thought that pin 7 was the actual power and pin 4 was just a 
signal? Therefore, for example, 5V on 7 and 3.3V on 4 would be OK?

Rog.

"larwe" <z...@gmail.com> wrote in message 
news:1...@g43g2000cwa.googlegroups.com...
>
> t...@my-deja.com wrote:
>> >However you should note that the documentation is not exactly right, and 
>> >there
>> >are some things I don't completely understand:
>>
>> our AVR-USB-JTAG have opto-isolatation between USB and target, this is
>> why you have to feed power from target too :)
>
> Right, I do understand this - but the documentation is a little bit
> confusing.
> 

Roger wrote:
> My JTAG Cable1 has just failed and I need to get another JTAG programmer, 
> ideally with a USB interface although if it has to be serial so be it. 
> Obviously I'd get an Atmel JTAG ICE Mk11 if the cost wasn't so ridiculously 
> high so it'll have to be an alternative.
> 
> What are people's views on the best one available at the moment?

I know of two ready made alternatives:

Olimex makes both serial and USB version
(http://www.olimex.com/dev/index.html) and you can buy them in US from 
http://www.sparkfun.com/shop/index.php?shop=1&cart=555824&cat=4&;

We use both serial and USB at work and they're ok once you get then 
going (docs aren't that great but the product is fine).

Propox also has serial and USB JTAG which seems to work with wider range 
of supply voltage according to spec. but they might be not isolated(?)
http://www.propox.com/products/t_99.html
http://www.propox.com/products/t_117.html
they seem to have US agent, see 
http://www.avrfreaks.net/index.php?module=FreaksVendors&func=displayVendor&id=159 
for more info.

You can also make one yourself, there are complete projects including 
PCB, bootloader and instructions on the net. Can't find one in english 
right now but as long as you understand electronics you should be ok.

http://liku.sdfpau.org/avrjtag.html
http://home.sch.bme.hu/~cell/atmel/AVR_JTAG/

Tom

On Thu, 26 Jan 2006 13:54:38 GMT, "Roger" <e...@rwconcepts.co.uk>
wrote:

>My JTAG Cable1 has just failed and I need to get another JTAG programmer, 
>ideally with a USB interface although if it has to be serial so be it. 
>Obviously I'd get an Atmel JTAG ICE Mk11 if the cost wasn't so ridiculously 
>high so it'll have to be an alternative.
>
>What are people's views on the best one available at the moment?

If you are going to use DebugWire (standard on all newer chips with low
pincount), the MKII is your only choice. Plus it handles USB at full speed
natively (Philips USB controller connected to one of the two Mega128)
without having to go through a serial bottleneck.

So it has it's price, but it's worth it. At least for me.

Mit freundlichen Grüßen

Frank-Christian Krügel

How reliable are the AVR's flash?
I have two Atmega169 (in AVR butterfly) failing.
They are supposed to last 10,000 cycles.
And yet, one failed after hundreds of cycles
and the second failed exactly after one cycle.

I can't program either one of them anymore.
The first one refuse to verify and the second
one verified but still contain the previous version.

If it's so difficult to program them, perhap I should
switch to PLCC (44 pins) socket rather than MLF (64 pins).

linnix wrote:
> How reliable are the AVR's flash?
> I have two Atmega169 (in AVR butterfly) failing.

How are you reprogramming them? What's the power supply?

I haven't had this problem, though I don't use that specific part.

linnix wrote:
> How reliable are the AVR's flash?
> I have two Atmega169 (in AVR butterfly) failing.
> They are supposed to last 10,000 cycles.
> And yet, one failed after hundreds of cycles
> and the second failed exactly after one cycle.
> 
> I can't program either one of them anymore.
> The first one refuse to verify and the second
> one verified but still contain the previous version.

The second sounds unlikely : ie How can it verify the wrong code ?

If they are not secured, you should be able to read back the code, and 
then compare with the nearest HEX version - that can give an idea of
failure modes.

-jg