AVR-Chat

Having some startup issues here with the M168 and new JtagiceMkII on 
an STK-500.

I'm porting my bootloader from M128 to the 168, and I thought I'd 
take the easy way, and use a DIP 168 on the STK500. 

So after a lot of searching again, I finally found a ref to 
installing the 168 in the SCKT3200A2 socket, using the green SPROG2, 
removing the RESET jumper to allow debugwire, and was able to load 
the app.

Unfortunately, the fuses weren't set up right, so I had to get out of 
debugwire and use ISP mode to set the fuses.. Ok that looks good, but 
now the part seems to be "stuck" somewhere, I can't talk to it in 
debugwire, or in ISP mode.

Any pointers?   

There's nothing connected to the port pins, for the moment it's just 
power and reset.  I have the device set to internal 8 mhz RC clock.

At 03:52 AM 19/01/2008, you wrote:
>I have the device set to internal 8 mhz RC clock.

Maybe...Does any code run in the chip to verify that the
clock is in fact working? At times the fuses get messed up.

2 options:

Try a new chip.

Use HVPP to check/reprogram the fuses.

At times, unplugging the debugger and restarting Studio fixes
some things.

You only asked for pointers, miracles take a little longer
as they say :-)


Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

Hi Dave,
              I have had some problems with debugwire going wrong when using
an earlier version of studio (caused by "myself not familiar with using
debugwire" not entering and exiting debugwire properly) the only solution
that I found was to completely uninstall studio, reboot and reinstall studio
(something to do with studio's use of the registry I think).
Might be worth a try.

Owen.

________________________________________

From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of Dave VanHorn
Sent: Saturday, January 19, 2008 3:53 AM
To: AVR-Chat@yahoogroups.com
Subject: [AVR-Chat] Debugwire, stk-500 and M168


Having some startup issues here with the M168 and new JtagiceMkII on 
an STK-500.

I'm porting my bootloader from M128 to the 168, and I thought I'd 
take the easy way, and use a DIP 168 on the STK500. 

So after a lot of searching again, I finally found a ref to 
installing the 168 in the SCKT3200A2 socket, using the green SPROG2, 
removing the RESET jumper to allow debugwire, and was able to load 
the app.

Unfortunately, the fuses weren't set up right, so I had to get out of 
debugwire and use ISP mode to set the fuses.. Ok that looks good, but 
now the part seems to be "stuck" somewhere, I can't talk to it in 
debugwire, or in ISP mode.

Any pointers? 

There's nothing connected to the port pins, for the moment it's just 
power and reset. I have the device set to internal 8 mhz RC clock.

--- In AVR-Chat@yahoogroups.com, "Owen" <oldhat_owen@...> wrote:
>
> Hi Dave,
>               I have had some problems with debugwire going wrong 
when using
> an earlier version of studio (caused by "myself not familiar with 
using
> debugwire" not entering and exiting debugwire properly) the only 
solution
> that I found was to completely uninstall studio, reboot and 
reinstall studio
> (something to do with studio's use of the registry I think).
> Might be worth a try.


I just tried it with another device. 
I was able to get in and set the fuses except for the DBW fuse, and 
then on entering debug, I selected to use SPI to put the part in DBW 
mode. After that, the part is inaccessible either way. 

Not happy.

At 08:16 AM 22/01/2008, you wrote:
>  After that, the part is inaccessible either way.

Once in DW mode the only thing that will revert the chip to
normal mode is either exiting DW from within a debug session
or resetting the fuse via HVPP.

Are you using the Dragon or JTAG Mk2 for debugging?

Just to refresh my memory, do you have a 4K7 or 10K pullup
on the reset pin? ("THEY" say it is not necessary) and of
course no cap.

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

On Jan 21, 2008 4:43 PM, John Samperi <samperi@ampertronics.com.au> wrote:
> At 08:16 AM 22/01/2008, you wrote:
> >  After that, the part is inaccessible either way.
>
> Once in DW mode the only thing that will revert the chip to
> normal mode is either exiting DW from within a debug session
> or resetting the fuse via HVPP.

Well, I'm not sure WHAT mode the chip is in now.
I can't talk to it with ISP, or Debugwire.
It was in ISP mode, and I exited the programmer, and started debugging.
At that point, it told me that the debugwire wasn't enabled (correct)
and I told it to use ISP mode to enable debug wire.
That was the last I was able to talk to the chip.

> Are you using the Dragon or JTAG Mk2 for debugging?

MkII

> Just to refresh my memory, do you have a 4K7 or 10K pullup
> on the reset pin? ("THEY" say it is not necessary) and of
> course no cap.

STK-500 with reset jumper removed.

On Jan 18, 2008 5:38 PM, Owen <oldhat_owen@yahoo.com.au> wrote:
> Hi Dave,
>              I have had some problems with debugwire going wrong when using
> an earlier version of studio (caused by "myself not familiar with using
> debugwire" not entering and exiting debugwire properly) the only solution
> that I found was to completely uninstall studio, reboot and reinstall studio
> (something to do with studio's use of the registry I think).
> Might be worth a try.

Tried that, no-go.

I might try it with a different pc, but all indications are that the
device is hosed up somehow.

I've been wondering about debugwire, perhaps I'll stick to tracing with 
"printf"...

DLC

David VanHorn wrote:
> On Jan 18, 2008 5:38 PM, Owen <oldhat_owen@yahoo.com.au> wrote:
>> Hi Dave,
>>              I have had some problems with debugwire going wrong when using
>> an earlier version of studio (caused by "myself not familiar with using
>> debugwire" not entering and exiting debugwire properly) the only solution
>> that I found was to completely uninstall studio, reboot and reinstall studio
>> (something to do with studio's use of the registry I think).
>> Might be worth a try.
> 
> Tried that, no-go.
> 
> I might try it with a different pc, but all indications are that the
> device is hosed up somehow.
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 

-- 
-------------------------------------------------
Dennis Clark          TTT Enterprises
www.techtoystoday.com
-------------------------------------------------

--- In AVR-Chat@yahoogroups.com, dlc <dlc@...> wrote:
>
> I've been wondering about debugwire, perhaps I'll stick to tracing 
with 
> "printf"...
>

Boy I tell ya.

I was able to get it working, intermittently.
When it works, I can debug pretty well.  BUT.

After working with it for a while yesterday, I hit a point where 
things were happening that made NO sense.  Then I noticed that it was 
having problems in the program flow.

Let's say we just executed these lines:

 clr zh
 ldi zl,$01

Can anyone tell me what the Z register should read?
Would you guess $3F01?

You can imagine this has rather interesting consequences for 
subsequent execution.

As far as I can tell from running, the ZH register really does have 
$3F in it.  I also caught it when I init the stack pointer, which 
looks like this:

Bootload:
	ldi	TEMP,low(RAMEND)		; $04FF
	out	SPL,TEMP			;Init stackpointer
	ldi	TEMP,high(RAMEND)		;
	out	SPH,TEMP			;

At the end of this, SP was something like $01FF, and that was where 
it was storing the data.  RAMEND is properly defined, I haven't 
touched it, and it used to work!

I powered the target down, shut down studio, rebooted, etc, several 
times, and every time afterward, I got the same errors at the same 
points in the code!

I posted this to AVR@atmel.com, along with a  jpg of the screen, 
showing my just having executed the clr zh, ldi zl,$01, with that and 
the contents of Z circled, and they replied, pointing me to a couple 
of useless FAQ articles, and closed the bug report.

I'm really pretty pissed at this point. 
I just spent $300 on a debugger, and I'm spending 80% of my time 
wrestling with the debugger.

What's it going to take to get workable debugging tools?
Do we need to show up and picket their booth at the next embedded 
systems conference?

<_grim_ chuckle>

  Now you know why Microchip is still the micro of choice, even if the
Atmel processors are faster and superior technology - Atmel support is,
er, sub-standard (IMO).  But I'm in the US, I think they are better
supported in the EU, but I'm not sure.  Regardless, I soldier on,  but I
don't use their debugging tools, I use "printf" and LED toggles.  Which
works for most stuff, but can get dicey when dealing with networking and
that ilk.  Atmel needs to spend less on glossy ads and more on FAE's and
tech support IMO.

DLC

> --- In AVR-Chat@yahoogroups.com, dlc <dlc@...> wrote:
>>
>> I've been wondering about debugwire, perhaps I'll stick to tracing
> with
>> "printf"...
>>
>
> Boy I tell ya.
>
> I was able to get it working, intermittently.
> When it works, I can debug pretty well.  BUT.
>
> After working with it for a while yesterday, I hit a point where
> things were happening that made NO sense.  Then I noticed that it was
> having problems in the program flow.
>
> Let's say we just executed these lines:
>
>  clr zh
>  ldi zl,$01
>
> Can anyone tell me what the Z register should read?
> Would you guess $3F01?
>
> You can imagine this has rather interesting consequences for
> subsequent execution.
>
> As far as I can tell from running, the ZH register really does have
> $3F in it.  I also caught it when I init the stack pointer, which
> looks like this:
>
> Bootload:
> 	ldi	TEMP,low(RAMEND)		; $04FF
> 	out	SPL,TEMP			;Init stackpointer
> 	ldi	TEMP,high(RAMEND)		;
> 	out	SPH,TEMP			;
>
> At the end of this, SP was something like $01FF, and that was where
> it was storing the data.  RAMEND is properly defined, I haven't
> touched it, and it used to work!
>
> I powered the target down, shut down studio, rebooted, etc, several
> times, and every time afterward, I got the same errors at the same
> points in the code!
>
> I posted this to AVR@atmel.com, along with a  jpg of the screen,
> showing my just having executed the clr zh, ldi zl,$01, with that and
> the contents of Z circled, and they replied, pointing me to a couple
> of useless FAQ articles, and closed the bug report.
>
> I'm really pretty pissed at this point.
> I just spent $300 on a debugger, and I'm spending 80% of my time
> wrestling with the debugger.
>
> What's it going to take to get workable debugging tools?
> Do we need to show up and picket their booth at the next embedded
> systems conference?
>
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>


-- 
Dennis Clark
TTT Enterprises

>  Now you know why Microchip is still the micro of choice, even if the
> Atmel processors are faster and superior technology - Atmel support is,
> er, sub-standard (IMO).  But I'm in the US, I think they are better
> supported in the EU, but I'm not sure.  Regardless, I soldier on,  but I
> don't use their debugging tools, I use "printf" and LED toggles.  Which
> works for most stuff, but can get dicey when dealing with networking and
> that ilk.  Atmel needs to spend less on glossy ads and more on FAE's and
> tech support IMO.

You know, back when I got into the AVR, the tools WORKED.
My ICE-200 was perfect, and even the ICE-50 was very good, UP TO the
point when they released it.
THAT rev was awful, and honestly, IMHO, it went downhill from there.

The Jtag ICE has been flaky, and I was really hoping that the MkII
would be an improvement.
No such luck.

Working with the 168 here, I'm going to be using the serial port in
the app, it would be a major pain to do diagnostics through it. What
I'm doing at the moment, is porting my M128 Xmodem loader over to the
168, because I don't need a 128 here, and the 168 is available in
automotive temperature grade.   The part that I'm having trouble with,
is the code that checks, and if needed sets the lock bits on entry to
the download, and again on exit (because I'm paranoid :)

Once I get the loader up and running, I have two apps to develop,
which I could reasonably debug through the serial port.

However, that's not really the point.

Even the lowly AVRISP has had it's share of unexplainable problems.  I
wasted an entire trip to a customer site, because studio flatly
refused to connect to my main, or backup AVRISP, even after installing
it on a borrowed laptop instead of the one I was using.  Serial ports
and cable were fine, and the whole rig had been tested the night
before.  When I travel like this, I test everything at home, then pack
up exactly that gear to take. I don't even sub "identical" serial
cables.

This pretty well sums it up for me.. http://www.youtube.com/watch?v=90ELleCQvew

And now that's broken.

Now I'm getting other non-deterministic junk in other places.
Basically, it's as if the ice is skipping some instructions according 
to some internal rule. 

I've seen this sort of problem in the ICE-50, Jtag Ice, and now the 
MkII.  Various platforms, with little to nothing in common electrically.
The common thread is studio, of course.


This stuff is a real developer's toolkit allright..
Full of rubber hammers.

Ok, things are becoming more interesting.  Below is my update to
avr@atmel.com, on my debugwire frustrations:


Additional info.

In the pic that I sent, you can see that the system failed to clear
ZH, even though it was straightline code, "clr ZH"

This has been absolutely consistent since it started happening,
through reboots, powerdown of target and debugger, etc.  I also
noticed that the debugger was failing to properly load up the stack
pointer, which is simply

ldi	TEMP,low(RAMEND)	; $04FF
out	SPL,TEMP	;Init stackpointer
ldi	TEMP,high(RAMEND);
out	SPH,TEMP	;

At the end of this, SP was $04XX where XX was whatever happened to be
in ZL when we came in.

Today I noticed the common thread.  BOTH of these points had
breakpoints set. Even though I wasn't USING the breakpoints, (I was
single-stepping), that was causing the problem.

I may not have read ALL the documentation, but as far as I'm aware,
setting a breakpoint is not supposed to also cause the debugger to
ignore the instruction at the breakpoint.

Please advise.

Has anyone used the ICE MK II with GDB or Avarice?  It'd be interesting to
see if those debuggers work better than the Atmel IDE.  The only reason
that I mentioned this ICE is that I own that one, so of course its more
interesting to me...  Does anyone have any experience at all with avarice
or GDB?

having fun now,
DLC

>
> And now that's broken.
>
> Now I'm getting other non-deterministic junk in other places.
> Basically, it's as if the ice is skipping some instructions according
> to some internal rule.
>
> I've seen this sort of problem in the ICE-50, Jtag Ice, and now the
> MkII.  Various platforms, with little to nothing in common electrically.
> The common thread is studio, of course.
>
>
> This stuff is a real developer's toolkit allright..
> Full of rubber hammers.
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>


-- 
Dennis Clark
TTT Enterprises

What's the secret to the JTAG-ICE.  I've had one for several years but haven't used it because it never wants to connect consistently.  I'm now on a project where it would be really nice to use but the silly thing won't talk to my ATmega128.  I've programmed the JTAG fuse, what else am I missing?

Regards,


Tim Gilbert
JEM Innovation Inc.
303-926-9053 (office)
303-437-4342 (cell)
720-890-8582 (fax)
www.jeminnovation.com
www.pdksolutions.com

[Non-text portions of this message have been removed]

I'm in the same boat.  The JTAG_ICE doesn't work with most AVR's I use,
and won't work with the ones it is supposed to work with...  Grr.

DLC

> What's the secret to the JTAG-ICE.  I've had one for several years but
> haven't used it because it never wants to connect consistently.  I'm now
> on a project where it would be really nice to use but the silly thing
> won't talk to my ATmega128.  I've programmed the JTAG fuse, what else am I
> missing?
>
> Regards,
>
>
> Tim Gilbert
> JEM Innovation Inc.
> 303-926-9053 (office)
> 303-437-4342 (cell)
> 720-890-8582 (fax)
> www.jeminnovation.com
> www.pdksolutions.com
>
> [Non-text portions of this message have been removed]
>
>
>
>
> Yahoo! Groups Links
>
>
>
>


-- 
Dennis Clark
TTT Enterprises

On Jan 24, 2008 3:48 PM, Dennis Clark <dlc@frii.com> wrote:
> Has anyone used the ICE MK II with GDB or Avarice?  It'd be interesting to
> see if those debuggers work better than the Atmel IDE.  The only reason
> that I mentioned this ICE is that I own that one, so of course its more
> interesting to me...  Does anyone have any experience at all with avarice
> or GDB?

They tell me there's a new studio coming, a ground-up rewrite.
But my project is probably going to be complete before we see that release.


Somewhere, there has to be someone in atmel who understands that the
purpose of these tools is to make our lives EASIER, and help us
deliver more working code FASTER.   IMHO those points are being
missed, entirely.

On Jan 24, 2008 3:50 PM, Tim Gilbert <tim@jeminnovation.com> wrote:
> What's the secret to the JTAG-ICE.  I've had one for several years but haven't used it because it never wants to connect consistently.  I'm now on a project where it would be really nice to use but the silly thing won't talk to my ATmega128.  I've programmed the JTAG fuse, what else am I missing?

I've used the regular jtag ice with the M128 since the M128 came out.
Not without problems and the odd day or two where it just refuses to
work at all for no apparent reason.

1: Is there anything else on the Jtag interface pins into the M128?
There can be, but you need to provide resistor isolation so that the
Jtag always wins when it wants to drive the lines.

2: Clocking issues.  If you're using a crystal or external resonator,
BE ABSOLUTELY SURE that you don't have the clock fuse set for the low
power "vittoz" mode oscillator.  You want the full-swing version.
Check clock osc output, it should be almost rail to rail.

3: 10k pullup on reset, 0.1uF to ground.

Other than that, it should just work.  (for suitably loose definitions
of "work", in this case)

The problem is that these things are like dog food.  The consumer and the
purchaser have different priorities.  I'm sure that if you got a few beers
into an Atmel exec, they'd tell you the purpose of the studio is to sell
parts by making people like us think it will make our lives easier and allow
us to deliver more working code faster.  By the time we discover the bugs
we're committed to their parts and when the next project rolls around, we'd
rather deal with a bug set we've learned than to fight the same battles
again with another IDE for another vendor's part.

-----Original Message-----
From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
Of David VanHorn
Sent: Thursday, January 24, 2008 1:08 PM
To: AVR-Chat@yahoogroups.com
Subject: Re: [AVR-Chat] Re: Debugwire, stk-500 and M168

On Jan 24, 2008 3:48 PM, Dennis Clark <dlc@frii.com> wrote:
> Has anyone used the ICE MK II with GDB or Avarice?  It'd be interesting to
> see if those debuggers work better than the Atmel IDE.  The only reason
> that I mentioned this ICE is that I own that one, so of course its more
> interesting to me...  Does anyone have any experience at all with avarice
> or GDB?

They tell me there's a new studio coming, a ground-up rewrite.
But my project is probably going to be complete before we see that release.


Somewhere, there has to be someone in atmel who understands that the
purpose of these tools is to make our lives EASIER, and help us
deliver more working code FASTER.   IMHO those points are being
missed, entirely.


 
Yahoo! Groups Links






-- 
No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.516 / Virus Database: 269.19.10/1241 - Release Date: 1/24/2008
9:58 AM

Regarding below:
No other connections on the JTAG bus.
Running with internal clock at 8MHz.
I have always used a 100K pull resistor on Reset; is that too weak?

Tim

  ----- Original Message ----- 
  From: David VanHorn 
  To: AVR-Chat@yahoogroups.com 
  Sent: Thursday, January 24, 2008 2:12 PM
  Subject: Re: [AVR-Chat] Atmel JTAG-ICE MkII


  On Jan 24, 2008 3:50 PM, Tim Gilbert <tim@jeminnovation.com> wrote:
  > What's the secret to the JTAG-ICE. I've had one for several years but haven't used it because it never wants to connect consistently. I'm now on a project where it would be really nice to use but the silly thing won't talk to my ATmega128. I've programmed the JTAG fuse, what else am I missing?

  I've used the regular jtag ice with the M128 since the M128 came out.
  Not without problems and the odd day or two where it just refuses to
  work at all for no apparent reason.

  1: Is there anything else on the Jtag interface pins into the M128?
  There can be, but you need to provide resistor isolation so that the
  Jtag always wins when it wants to drive the lines.

  2: Clocking issues. If you're using a crystal or external resonator,
  BE ABSOLUTELY SURE that you don't have the clock fuse set for the low
  power "vittoz" mode oscillator. You want the full-swing version.
  Check clock osc output, it should be almost rail to rail.

  3: 10k pullup on reset, 0.1uF to ground.

  Other than that, it should just work. (for suitably loose definitions
  of "work", in this case)


   

[Non-text portions of this message have been removed]

--- David VanHorn <microbrix@gmail.com> wrote:

> On Jan 24, 2008 3:48 PM, Dennis Clark <dlc@frii.com>
> wrote:
> > Has anyone used the ICE MK II with GDB or Avarice?
>  It'd be interesting to
> > see if those debuggers work better than the Atmel
> IDE.  The only reason
> > that I mentioned this ICE is that I own that one,
> so of course its more
> > interesting to me...  Does anyone have any
> experience at all with avarice
> > or GDB?
> 
> They tell me there's a new studio coming, a
> ground-up rewrite.
> But my project is probably going to be complete
> before we see that release.
> 
> 
> Somewhere, there has to be someone in atmel who
> understands that the
> purpose of these tools is to make our lives EASIER,
> and help us
> deliver more working code FASTER.   IMHO those
> points are being
> missed, entirely.

What are the "big" developers using?  If they're
having trouble with Atmel's tools, sales will suffer
and Atmel _will_ notice that.

Jeff Engel
Arlington, TX

Happiness is - positive intake manifold pressure.


      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

At 07:56 AM 25/01/2008, you wrote:
>   I'm in the same boat.  The JTAG_ICE doesn't work with most AVR's I use,
>and won't work with the ones it is supposed to work with...  Grr.

The OLD JTAG mk1 only works with a limited number of OLDER
chips, the newer JTAG MK2 works with all chips.

I use the old (homemade) mk1 with M16/M32/M64 and M128,
the JTAG of the Dragon with newer chips like the M164P
as well as the older chips.

What is the problem with your set up that "won't work"?
Do you have a properly setup JTAG port?

JTAG and OCDEN fuses need to be enabled for debugging.
OCDEN seems to be automatically set up at debug time
but I have mine checked anyway during debug sessions.

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

> What are the "big" developers using?  If they're
> having trouble with Atmel's tools, sales will suffer
> and Atmel _will_ notice that.

Last winter, I asked Sarah Cox of Barnett, Cox, and OCull (now Priio)
She said they'd given up on using studio entirely.
Pretty much the same experiences I had.

They were using codevision, and doing debug thru serial.

But in a lot of smaller apps, that's an issue.
I could resurrect my "pong" code, and output bytes in clocked serial
on two pins, but that's a real PITA.
Then again, so's this.

Is the M103 compatibility fuse set?  That was another big timewaster
if you missed it.

On Jan 24, 2008 4:20 PM, Tim Gilbert <tim@jeminnovation.com> wrote:
> Regarding below:
> No other connections on the JTAG bus.
> Running with internal clock at 8MHz.
> I have always used a 100K pull resistor on Reset; is that too weak?
>

That is pretty weak. 50uA.
I'd go with 10k

Hi All,
FWIW, I have been using JTAG ICE and JTAGICE-MkII for a number of years with
little or no problems.

One things that I have not seen mentioned already is that the JTAG clock
frequency must exceed 1/4 of the  CPU/Xtal freq.
In all random 'disconnects' that I remember they have been due to forgetting
to set the JTAG clock  freq in AVR Studio

HTH
Ivan Vernot

> -----Original Message-----
> From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On Behalf
> Of Dennis Clark
> Sent: Friday, 25 January 2008 7:56 AM
> To: AVR-Chat@yahoogroups.com
> Subject: Re: [AVR-Chat] Atmel JTAG-ICE MkII
> 
>   I'm in the same boat.  The JTAG_ICE doesn't work with most AVR's I use,
> and won't work with the ones it is supposed to work with...  Grr.
> 
> DLC
> 
> > What's the secret to the JTAG-ICE.  I've had one for several years but
> > haven't used it because it never wants to connect consistently.  I'm now
> > on a project where it would be really nice to use but the silly thing
> > won't talk to my ATmega128.  I've programmed the JTAG fuse, what else am
> I
> > missing?
> >
> > Regards,
> >
> >
> > Tim Gilbert
> > JEM Innovation Inc.
> > 303-926-9053 (office)
> > 303-437-4342 (cell)
> > 720-890-8582 (fax)
> > www.jeminnovation.com
> > www.pdksolutions.com
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> 
> 
> --
> Dennis Clark
> TTT Enterprises
> 
> 
> 
> 
> Yahoo! Groups Links
> 
> 
>

At 01:21 PM 25/01/2008, you wrote:
>JTAG clock frequency must exceed 1/4 of the  CPU/Xtal freq.

Must EXCEED or MUST NOT exceed 1/4 of the clock? :-)

@Ivan..our programmers seem a little overdue. I always get this
feeling of people fleeing to countries without extradition treaties
with my money....



Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

> One things that I have not seen mentioned already is that the JTAG clock
> frequency must exceed 1/4 of the  CPU/Xtal freq.
> In all random 'disconnects' that I remember they have been due to forgetting
> to set the JTAG clock  freq in AVR Studio

Ok, where does one set that on a MkII, and why wouldn't it work with a
stock AVR at 1 MHz, let alone at 8 MHz?

Thanks for all the suggestions.  However, I switched to a 10K resistor and everything works.  Well, mostly works, I did get one "can't read signature" error but it seems to debug and program ok now.  I assume that there is enough capacitance that the 100K won't pull the line up fast enough.

I had a similar problem with too small a resistor when using the ISP.  Haven't tried it with the 10K yet.

Regards,

Tim Gilbert
JEM Innovation Inc.
303-926-9053 (office)
303-437-4342 (cell)
720-890-8582 (fax)
www.jeminnovation.com
www.pdksolutions.com

  ----- Original Message ----- 
  From: David VanHorn 
  To: AVR-Chat@yahoogroups.com 
  Sent: Thursday, January 24, 2008 2:30 PM
  Subject: Re: [AVR-Chat] Atmel JTAG-ICE MkII


  On Jan 24, 2008 4:20 PM, Tim Gilbert <tim@jeminnovation.com> wrote:
  > Regarding below:
  > No other connections on the JTAG bus.
  > Running with internal clock at 8MHz.
  > I have always used a 100K pull resistor on Reset; is that too weak?
  >

  That is pretty weak. 50uA.
  I'd go with 10k


   

[Non-text portions of this message have been removed]

On Jan 24, 2008 11:14 PM, Tim Gilbert <tim@jeminnovation.com> wrote:
> Thanks for all the suggestions.  However, I switched to a 10K resistor and everything works.  Well, mostly works, I did get one "can't read signature" error but it seems to debug and program ok now.  I assume that there is enough capacitance that the 100K won't pull the line up fast enough.
>
> I had a similar problem with too small a resistor when using the ISP.  Haven't tried it with the 10K yet.


I added a 10k to my STK-500 today, still same with the MkII

--- In AVR-Chat@yahoogroups.com, "Ivan Vernot" <ivernot@...> wrote:

> ... the JTAG clock frequency must
> exceed 1/4 of the CPU/Xtal freq.

I think you might be confusing JTAG with ISP.  JTAG programming works 
even with the microcontroller clock misconfigured and not running.

Graham.

At 11:38 PM 25/01/2008, you wrote:
>I think you might be confusing JTAG with ISP.  JTAG programming works
>even with the microcontroller clock misconfigured and not running.

I think Ivan was talking about JTAG DEBUGGING, (I was anyway)
in which case the 1/4 of the target clock is still required
according to the JTAG Option connection window.

Regards

John Samperi

********************************************************
Ampertronics Pty. Ltd.
11 Brokenwood Place Baulkham Hills, NSW 2153 AUSTRALIA
Tel. (02) 9674-6495       Fax (02) 9674-8745
Email: john@ampertronics.com.au
Website  http://www.ampertronics.com.au
*Electronic Design * Custom Products * Contract Assembly
********************************************************

On Jan 25, 2008 4:06 PM, John Samperi <samperi@ampertronics.com.au> wrote:
> At 11:38 PM 25/01/2008, you wrote:
> >I think you might be confusing JTAG with ISP.  JTAG programming works
> >even with the microcontroller clock misconfigured and not running.
>
> I think Ivan was talking about JTAG DEBUGGING, (I was anyway)
> in which case the 1/4 of the target clock is still required
> according to the JTAG Option connection window.

AFAIK it's not an issue with the MkII, except in ISP mode, and I've
tried changing those settings down to 62 kHz.
If that's not slow enough, nothing is.