Very strange problem with Atmega644p and Jtagice mkII

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

I'm running into a very strange problem with an Atmega644p. The AVR is running in default mode (internal RC with CKDIV8) and only the 4 JTAG lines are connected, NOTHING ELSE.

I have reduced the problem to the simple test case below. Every time line 17 is executed in the debugger, the AVR goes haywire. Line 17 is nothing but an OUT PORTA,0x10.
The haywire part is that ALL Data memory (incl. all the registers) are set to the value 0xff and the AVR jumps to location 0.
Before the problem was reduced to this minimal test case, the flash was also shown as having the value 0xff.

Compile with -Os for an Atmega644p, then step 6 times. When at line 17, switch to disassembly mode and step to the OUT instruction. Executing the OUT instruction in disassembly mode causes the AVR to go crazy (at least for me).

I'm hoping that someone is willing to see if this reproduces.

Similar problems occur with the Atmega324p but not this reduced test case. When not executing line 17 in assembly mode, the dreaded messages "JTAGICE mkII: IDR event oxff" appear (or just a hang).


//
// Fails on Atmega644p, running at 1 Mhz (internal RC with /8). Compile with -Os.
//
// With Jtagice mkII, step 6 times. When executing line 17. AVR good crazy. Disassembly
// mode shows the AVR jumps to location 0 and ALL the data area (incl. registers) is 0xff.
//
#include 

typedef unsigned char  uint8;


uint8 foo(uint8 x, uint8 y)
{
	if (y < 16) {
		PORTA = y;
	} else {
		PORTA = y & 0x1f;		//Line 17
	}	

	return (x & 0x0f);
}



int main(void)
{
	uint8 i, j, Vx, Vy;
	PORTA = 0;
	DDRA = 0xff;


	Vy = 15;		// Must be 15. Start at 16 and problem goes away.
	do {
		Vx = 0;
		j = foo(Vx, Vy);			//Vx, Vy
	} while (++Vy);						// until wrap


	do {

		if (++i == 255) {
			i = 0;
		}

	} while (1);
}

jrseattle

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

A quick update. I tried this test on an STK600 (with a Jtagice mkII) and it passed. But the test below (slightly modified) fails:

//
// Fails on Atmega644p, running at 1 Mhz (internal RC with /8). Compile with -Os.
//
// With Jtagice mkII, step 6 times. When executing line 19. AVR good crazy. Disassembly
// mode shows the AVR jumps to location 0 and ALL the data area (incl. registers) is 0xff.
//
// Now also fails on STK600 when PORTA is assigned the value of 0x40.
//
#include 

typedef unsigned char  uint8;


uint8 foo(uint8 x, uint8 y)
{
	if (y < 16) {
		PORTA = y;
	} else {
		PORTA = y & 0xff;		//Line 19
	}	

	return (x & 0x0f);
}



int main(void)
{
	uint8 i, j, Vx, Vy;
	DDRA = 0xff;

	Vy = 0x3d;
	do {
		Vx = 0;
		j = foo(Vx, Vy);			//Vx, Vy
	} while (++Vy);						// until wrap


	do {

		if (++i == 255) {
			i = 0;
		}

	} while (1);
}


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

Quote:

only the 4 JTAG lines are connected, NOTHING ELSE.

Err.. Vcc and Gnd's ?? The IDR message usually results from noisy JTAG signals (possibly cables too long?)

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

Might I suggest that you attach a LED to one of the free ports, and flash it a couple of times only AFTER that line? This way if it is the JTAG interface failing, but the micro really works ok, you will know.

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

// With Jtagice mkII, step 6 times. When executing line 19. AVR good crazy. Disassembly
// mode shows the AVR jumps to location 0 and ALL the data area (incl. registers) is 0xff.
//

I'm glad you posted this, I have been extremely frustrated by an issue that sounds almost identical.

I'm seeing the kinds of behaviour you describe, and more.

I'm using a 20 MHz M644, and Jtag Ice Mkii.

I'm not having consistent problems, but I just lost all of yesterday to these problems, and it's still happening today.

This morning, I can step my app through to where I enable interrupts, then when I single-step that instruction, the ICE looses control of the target, and either thinks that the target is running, or it ends up back at the reset vector. I've made no changes to the interrupt vector table, or interrupt code in days.

I'm also seeing where the ice will "loose control" of the target, thinking that it's stepping when the target has "escaped" and is running full speed.

Yesterday, the WDT was enabled constantly, even though the fuse settings, and code I added to turn off the WDT are saying it should be off. The turnoff code works in sim, but not in the chip. Worse, I can't even load the code to the chip using the Jtag as a chip programmer.

So far, my MkII, my Atmel Serial Jtag, and my two "clone" serial Jtags are all acting like this.

I'd blame this on the target, or the PC, or power, but I've had so many different pieces over the years.

I'd sent the problem to the support people last week, and got a nice "form letter" response, and nothing more.

My experience with the tools, Ice-50, Jtag Ice, MkII, and even the AVRISP over the last 5 years or so, on different targets, computers, etc, has been that they work when they want to..

Last year, I documented a problem where in single-stepping I saw the code (asm) load a register with a value, and leave the value in the register unchanged. This was on a 16 Mhz M128. I went so far as to install a virtual PC, and install Studio on that, and then to capture what happened in a video that I sent to them, and posted on AVR-Chat at yahoo groups.

At the moment, I'm working with Arrow to get the Atmel FAE in here to see this. It's completely unpredictable though.. I've seen the tools behave bizarrely for hours, or days at a time, then mysteriously go back to working normally.

Unfortunately, I don't have a solution for you, but I can commiserate.

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

Dave, thanks for your reply. Yes, this erratic debugger behaviour is extremely frustrating.
The second example I posted reproduces the problem EVERY TIME on an STK600 with a JTAGICE MKII and an Atmega644P. How can I get the local Atmel FAE in Bellevue WA interested? I want to demo this for them.

In general, my original project is not working as expected. Using the JTAGICE MKII shows that unexpected code paths are being taken but can I trust this?
Here is a code sample:

cli();
HP = HeadPtr;
TP = TailPtr;
state = 1;
if (HeadPtr == TailPtr) {
	sei();
	break;
} else {
	foo();
	if (TailPtr == HeadPtr) {
		DebugL2();
	}
}

Note: foo() does nothing but is needed to avoid optimizating the second test away.

How can DebugL2() ever be executed with interrupts disabled?

Stumped.

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

OK, here is a minimal test case. The second "out PORTA,16" always causes the Jtagice mkII to lose it.

If anyone has a Jtagice mkII and a Atmega644p (dip), please try to reproduce this.

jrseattle

;
; 40-pin DIP Atmega644p at 1 MHz (internal RC with CKDIV8 fuse set)
; mounted on STK600 and JTagice mkII connected. Nothing else
;
#include 


	.cseg
	jmp		Main


Main:
	ser		r16
	out		DDRA,r16

	ldi		r16,0x3f
	out		PORTA,r16
	inc		r16
	out		PORTA,r16	; <<<<< JTAGICE MKII step fails. "JTAGICE mkII: IDR event 0xff." errors

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

You do realize that if you have interrupts enabled and you single step you WILL end up in the interrupt service routine NOT the next line of your program. I work on embedded systems with AVR processors that have many interrupts firing from several sources (timers, ehternet nics, etc) and it is impossible to single step unless you first disable interrupts globally. The only other choice is to keep clearing and setting new breakpoints. (Too bad the jtag usually only gives you 3 of them at a time).

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

I do realize that. Global interrupts are off in all the test cases (they are off by default).
Anyway, the problem is not that I end up in an ISR when stepping; I end up at location 0, with all SRAM memory (incl. control registers) clobbered to 0xff, or the Jtagice mkII just hangs, spewing out "IDR event 0xff" messages.

jrseattle

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

Quote:
The second "out PORTA,16" always causes the Jtagice mkII to lose it.
And you DO HAVE AVCC connected to VCC, correct? (Cliff hinted above and you may remeber that it also feeds porta)

As a matter of interest what is the JTAG target frequency set to? I have mine set to 1MHz even though I work with higher clock frequencies.

Of course David's case is hopeless as he insists on having his lab under the ladder factory and, he just revealed, next door to a broken mirror factory and we know that he likes running over black cats... :lol: Poor FAE he/she will have their work cut out.

Having said that C source debugging is a hit amd miss affair anyway it seems. :(
I had some test software written in the dark language which just sets up a few things and goes into a loop. Breaking JTAG will usually brings the arrow up in a source file that is included but not used in the endless loop. Switching to the disassembly view shows the arrow nicely chasing it's tail in the endless loop as it should. Search me sport!!

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Quote:

Having said that C source debugging is a hit amd miss affair anyway it seems.

OK, I'll bite: What part of jr's program is in C?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

All good points :). I moved the test case to the STK600 using nothing but the socket to guarantee correct connections of the required pins (VCC, AVCC etc). Then I moved the test case to assembler to remove all the complexities introduced by compiler optimizations.
Yes, the Jtagice mkII speed is set at 1 Mhz. I also tried the "Disable use of BREAK instruction for breakpoints" option but it made no difference.

The test case is now extremely simple and the problem happens EVERY TIME for me. Not sure if my Atmega644P chip is faulty of course. I still have two Jtagice mkII units and it happens with both. The problem can be reproduced on a breadboard so I don't suspect the STK600 either. However I had similar problems with an Atmega324P (though not this simple test case).

I moved my original project to an Atmega644 (no P) and now I only see the message "JTAGICE mkII: IDR event 0xff” only occasionally.

jrseattle

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

Check your fuses and make sure that the watchdog timer isn't forced on. Sounds like you are being hit with a software reset.

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

I am so glad to see this post!

I also have a 644 problem much the same, but decided not to ask is it makes no sense whatsoever. I have a simple program in assembly which sends a VGA output to a monitor to display some test patterns. On a 324P, the program works perfectly. When I replace the 324P on my breadboard and drop in the 644p, the program resets randomly much like what you are describing.

Odd considering both the 324p and 644p are identical minus the memory sizes. My program is assembly, and yes I have the proper include file and device type set in AVRStudio.

I actually talked to Atmel about this last year and they suggested trying a new batch of 644s. At that point, I moved on to another project, but recently verified that the 644p (new batch) still acts strange with this program and a few others that toggle port pins at a high rate.

Some programs run fine on both the 324p and 644p, but others make the 644p freak right out.

Now I feel that there may be something wrong inside that 644p after hearing other similar reports.

To be honest, I have been really thinking about Pic24 again after seeing how the Xmega and 1284p situation is unfolding. Normally i support the underdog, but not when he snaps at me.

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

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

RTFM:

JTAGICE MKII AVRStudio manual wrote:
The communication speed between the JTAGICE mkII and the target AVR depends on the target frequency. Type the Target Frequency in the connection box. AVR Studio will set up the optimal communication speed out from the Target Frequency that is specified. Note that if the target is running on Internal RC Oscillator which is not calibrated, it may run on a lower frequency than expected. This can lead to problems with the communication.
The old ISP rule of using a fraction of the actual target frequency is misleading and doesn't appear to apply the JTAGICE MKII.

If you are running at 1 MHz internal RC, try reducing the target frequency by a small amount. If you are running at 20 MHz change the target frequency to 20 MHz.

I don't know if this will fix any problems or not, but it is worth a try.

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

OK, I checked the fuses for the millionth time: no watchdog enabled (WDTON not checkmarked in AVR Studio).
I also set the AVR clock speed at 8 Mhz (deselect CKDIV8), leaving the Jtagice mkII at 1 Mhz with exactly the same results.

I still hope someone is willing to try to reproduce this. If you have an Atmega644p and a Jtagice mkII, it should only take a couple of minutes using almost any type of test board.

Here us the test program again:

;
; 40-pin DIP Atmega644p at 1 MHz (internal RC with CKDIV8 fuse set)
; mounted on STK600 and JTagice mkII connected. Nothing else
;
#include 


	.cseg
	jmp		Main


Main:
	ser		r16
	out		DDRA,r16

	ldi		r16,0x3f
	out		PORTA,r16
	inc		r16
	out		PORTA,r16		;JTAGICE MKII step fails. "JTAGICE mkII: IDR event 0xff." errors

	rjmp	PC

In the meantime, I've moved my debugging method to LEDs and printf and am still seeing all kinds of strange behaviour, specifically two registers being swapped in a section of code where interrupts are disabled. How is this possible??? I'll start a new topic on this.

jrseattle

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

js wrote:
Quote:

Of course David's case is hopeless as he insists on having his lab under the ladder factory and, he just revealed, next door to a broken mirror factory and we know that he likes running over black cats... :lol: Poor FAE he/she will have their work cut out.
Quote:

If I can get them here..

Yeah, it started working properly this morning, no obvious reason, I just kept trying, restarting the target, Ice, PC..

I actually got in a productive half day!

I've seen those 0xFF messages too, I don't know what they mean..

I also found some interesting things once the ice decided to work..

1: Missing a semicoln after declaring an external.
extern uint8_t variable //<--- No ;
Causes wierd problems, and does not necessarily generate warnings or errors. I have -Wall and a bunch of other flags on for warnings.

2: Including external files in a way that seems entirely reasonable, isn't working right.

#ifdef Option1
#include "ISR-Opt1.inc
#endif
#ifdef Option2
#include "ISR-Opt2.inc"
#endif

The two files contain two versions of a T0 overflow int. When it's behaving badly, the T0 vector ends up at 0x0000. Including like this is supposed to work, according to the two software guys here, who use GCC on big linux systems. And it did work, but then it stopped.. I'm willing to believe that I did something else somewhere else that pissed off the compiler somehow.

I'm still having the ice sometimes loose control of the target, but today it was almost working properly.

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

Quote:
I still hope someone is willing to try to reproduce this.
I have the same set up here, I'll try it later on today.....BUT...you haven't told us yet if AVCC is connected. Can you please also MEASURE it just to be sure?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

jrseattle wrote:
I also set the AVR clock speed at 8 Mhz (deselect CKDIV8), leaving the Jtagice mkII at 1 Mhz with exactly the same results.
What I was quoting from the JTAGICE MKII manual said you should set the target frequqncy to 8 MHz, not 1 MHz. If you have trouble there because you are using the AVR internal RC oscillator, maybe as low as 7.2 MHz (-10%).
js wrote:
.....BUT...you haven't told us yet if AVCC is connected.
I'm not sure if jrseattle is listening to anyone or not. Maybe he is just ranting?

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

I apologize for being unclear. I do have AVCC connected. My comment re moving the test case to the STK600 was intended as an implicit answer since the STK600 automatically connects the AVCC on the socket (I actually measured this).

Re. the Jtagice mkII target frequency I have the following question: if I set the target frequency to a lower value than the actual frequency of the AVR, am I ok? I set the ACTUAL AVR frequency to 8 Mhz (maybe 7.2 Mhz) and the Jtagice mkII target frequency was still 1 Mhz. Assuming that the Jtagice mkII will target its clocking for a 1 Mhz device but the device is actually running at 7.2 Mhz or more, that should work fine.
Anyway, I only used the internal RC oscillator to get the simplest possible test case without outside dependencies. Before I was running at 20 Mhz and tested various target clock frequencies, none of which made a difference.

John, thanks for trying.

jrseattle

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

The AVR factory clock calibration is plus or minus 10 %. Data sheet version 8011L–AVR–02/09 page 331 section 25.3 Clock Characteristics. If your AVR clock is running at 8 MHz internal oscillator with CKDIV8 fuse unprogrammed (no divide by 8 ), then your AVR clock frequency is set to 8 MHz. It may actually be as low as 7.2 Mhz (minus 10 %). First try setting the JTAGICE MKII target frequency to 8 MHz. If this doesn't work you could program the CKOUT fuse and connect a frequency counter to pin PB0 to find the real internal RC oscillator frequency, or you could try a JTAGICE MKII target frequency as low as 7.2 MHz if you don't know the real RC oscillator internal frequency.

If you change the AVR RC clock to 1 MHz (such as programming the CKDIV8 fuse), they you must change the JTAGICE MKII target frequency to 1 MHz, or maybe go as low a minus 10% of 1 MHz lower in target frequency.

If you install and select a 20 MHz external crystal for the AVR clock with the CKDIV8 fuse unprogrammed (no divide by 8 ), then you set the JTAGICE MKII target frequency to 20 MHz.

I really don't know if setting the JTAGICE MKII up correctly will solve your problem or not. However, there is an AVR reset output on the 10 pin JTAG cable that is part of the JTAGICE MKII. A confused JTAGICE MKII might be resetting your AVR.

This is really important. If you open the AVRStudio Tools, Program AVR, Connect, JTAGICE mkii, (USB or COM depending on your connection), on the Main tab - is the device shown as the ATmega644P and can you read the correct signature? Is the Programming Mode set to JTAG mode?

This is for the JTAGICE MKII. Keep in mind serial ISP programmers are typically not set to the actual AVR clock frequency (always check the manuals).

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

Ok some tests happening.

M644p running at 14.7456MHz, JTAG target clock frequency at 1MHz.
The arrow loops back to main as soon as I hit the 1st "out PORTA,r16" , never makes it to "inc r16 ". :(

edit forcing the arrow to "inc r16 " with "set next statement" allows me to run to the end.

edit 2 if I "run to cursor" to "inc r16 " then I can step trough til the end otherwise it gets stuck to the 1st "out PORTA,r16". About to try on the laptop with Studio 4.14 (I think..)

edit 3 no joy with the laptop using Studio 4.14 same problems. :evil: May be a good time to let Atmel know and point to this thread maybe.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

John,

What I'm trying to find out is what happens when you run the JTAGICE MKII target frequency at 14.7456 MHz. Simple, but no one seems to want to try it.

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

Mike B wrote:
John,

What I'm trying to find out is what happens when you run the JTAGICE MKII target frequency at 14.7456 MHz. Simple, but no one seems to want to try it.

I've only got 16 MHz and 4 MHz crystals handy.

I did try setting the Jtag frequency lower, 10 MHz when talking to my 20 MHz target, but that didn't seem to make things better when they were bad, or worse when they were good..

Is PortA on that target connected to something that would draw a lot of current, either constantly, or pulse, like a capacitive load?

Reading the MCUCSR after reboot might be informative.
You'll have to zero it in the init, then catch it before it is cleared again and get the data. That will tell you why it thinks it's back at 0.

The other thing is to open up the assembly view, and step it thru, and see if it's jumping to zero, or what?

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

I may have found a solution to my origal problems, erratic behavior on the Atmega324p and created a new topic in this forum. See:

Warning: Atmega644, 644P and 324P and crystal settings

Brad and Dave: are you using external crystals in your designs? If so, please try the "Full Swing Oscillator" fuse to see if your erratic behavior goes away.

I will submit my Jtagice mkII problem to Atmel. Thanks everyone for your comments.

jrseattle

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

Quote:
like a capacitive load?
I came up to the same conclusion about 2am in my nightly nightmares. :? Of course, porta on the board I was testing with is used for inputs therefore it has 8 x 100nF caps for debouncing the inputs. :evil: that's what happens when one does things at the end of a Loooooong day!

Loading up the STK500 with a new chip and the leds wired up to porta it worked flawlessly with the internal 1MHz clock and 1MHz JTAG target frequency on the JTAG. Then switched to external oscillator at 14.7456MHz and 14.7MHz JTAG target frequency on the JTAG and also worked well.

Just to be sure I switched chips and it still worked well.

And finally JR you have made David's day with his hobby horse. :lol: see my other post.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

jrseattle wrote:

Brad and Dave: are you using external crystals in your designs? If so, please try the "Full Swing Oscillator" fuse to see if your erratic behavior goes away.

jrseattle

Yeah, I wrote the book on that one, found it in 2001 or 2002, on the M128. It was a miserable experience.
Worse, I'd specified that they program the chips with the full-swing mode enabled, since I didn't have any info on using the low power mode, but the instructions got changed, and they used the low power mode instead.

Over on avr-chat at yahoogroups, I posted an app for a "one chip wonder" that plugs into the programming port and fixes the fuses. It's bailed out a couple of friends who shipped product with the wrong settings.

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

js wrote:

And finally JR you have made David's day with his hobby horse. :lol: see my other post.

Yeah well.. IMHO that information can't get put out there often or loud enough. Why they made that mode the default in the M128... The 103 compatibility fuse was one thing, it hoses things up pretty well, and it ALWAYS hoses them up. The CKOPT fuse is very very sneaky.

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

>insert long and unprintable cursing which wouldn't be acceptable for a public forum<

Dammit! I've been bit by that @!@##!$ CKOPT fuse again! I didn't read the options closely enough.. It seems that they've decided to stop calling it CKOPT, and rolled it in with the rest of the bits.

My low fuses were 0xDF, which selected that damnable low power mode!.. I should have been using, and AM NOW USING 0xD7, which is the full swing mode.
Verified on scope, it was about 1/2VCC amplitude.

Did I mention it's very very sneaky....
>fume...<

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

This may be an obvious question to some, but here it is anyway:

Is it ok to leave output ports unconnected and set them anyway?

I'm asking because my Jtagice mkII test case fails as described when PORTA is unconnected, but works just fine when the pins being set are connected to an LED (w/resistor).

jrseattle

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

Yes, unconnected pins should either be outputs, or inputs with pullups on, but you can absolutely drive an unconnected pin high, or low, or toggle/flash/random/whatever.

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

jrseattle,

You probably want to read AVR040 and AVR042

http://www.atmel.com/dyn/product...

Cliff

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

I can't find any detailed documentation on the STK600. However, the STK500 external crystal socket is for a complete external oscillator circuit. I was wondering if any of these reported clock CKOPT fuse problems were setting the 644P fuses to use an external crystal, when they might have actually needed to be set to an external clock instead?

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

Quote:

I was wondering if any of these reported clock CKOPT fuse problems were setting the 644P fuses to use an external crystal, when they might have actually needed to be set to an external clock instead?

On the STK500 it doesn't matter. It's a fairly powerful oscillator and just as the standard "get out of jail free" trick for recovering ISP it doesn't really matter whether the AVR itself is fused for crystal or ext-oscillator it'll power its way up the XTAL1 pin anyway.

The CKOPT thing only comes into play when a piece of quartz close to the AVR with nothing but a couple of caps is involved.

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

True, but we are not talking about getting out of jail and recovering from incorrect AVR oscillator fuse programming.

I believe the new bug report is the low power crystal crystal oscillator causes ATmega644P malfunctions that using full swing crystal oscillator corrects. CKOPT has been used as a more familiar equivalent terminology for full swing and I don't think anyone has actually claimed the 644P has a "CKOPT" fuse.

My point is just in case the 644P oscillator fuses should have really been set to external clock and not to low power or full swing external crystal, then maybe this reported bug doesn't exist? I'm only asking the question, especially since I can't find complete STK600 information.

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

Mike B wrote:
True, but we are not talking about getting out of jail and recovering from incorrect AVR oscillator fuse programming.

I believe the new bug report is the low power crystal crystal oscillator causes ATmega644P malfunctions that using full swing crystal oscillator corrects. CKOPT has been used as a more familiar equivalent terminology for full swing and I don't think anyone has actually claimed the 644P has a "CKOPT" fuse.

True, but the 644 does have the "low power" and "full swing" crystal oscillators, which was what the CKOPT fuse was about.. Seems like different name, same game.

Quote:

My point is just in case the 644P oscillator fuses should have really been set to external clock and not to low power or full swing external crystal, then maybe this reported bug doesn't exist? I'm only asking the question, especially since I can't find complete STK600 information.

In my case, I definitely do NOT want external oscillator, I want crystal. I just only ever want "full swing".

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

In my lab, I only use ISP with my STK500 and always an external clock oscillator module, so fuses are set to EXT. I am getting interested in this quirk again now as I intend to use a 644p once again soon.

If this mystery is still unsolved when I get back to it, I will include a lot more in my report. I know I was vague, but it still baffles me that by only changing the device from a 324p to a 644p would cause a total failure in such a simple program.

Brad

jrseattle wrote:

Brad and Dave: are you using external crystals in your designs? If so, please try the "Full Swing Oscillator" fuse to see if your erratic behavior goes away.

jrseattle

I Like to Build Stuff : http://www.AtomicZombie.com

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

I'm looking at that now with my M644 @ 20Mhz, using Jtag ice MkII

In C:

uint8_t TEMP;
DDRA = 0xFF; // I'm assuming this needs to be all outputs?
Temp = 0x00;
PORTA = Temp;
Temp = 0xFF;
PORTA = Temp;

The above executes fine here. It didn't use R16 though, as below:

384:      	DDRA = 0xFF;
+0000094E:   EF8F        SER       R24            Set Register
+0000094F:   B981        OUT       0x01,R24       Out to I/O location
386:      	PORTA = Temp;
+00000950:   B812        OUT       0x02,R1        Out to I/O location
388:      	PORTA = Temp;
+00000951:   B982        OUT       0x02,R24       Out to I/O location
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did this ever get resolved for you? I have my FAE coming in today at 2:30.

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

No resolution. The local Atmel FAE came to my office, saw the problem being reproduced on the STK-600 and submitted it to Atmel: ATTicket: 540519.

I am a little suspicious of my Atmega644p chip since it behaves so much more erratic than my other AVR chips (Atmega644, Atmega324p). Unfortunately, it's the only Atmega644p I have right now.

Just for completeleness: the test case I submitted only reproduces if PortA is UNCONNECTED.

; 
; 40-pin DIP Atmega644p at 1 MHz (internal RC with CKDIV8 fuse set) 
; mounted on STK600 and JTagice mkII connected. Nothing else 
; 
#include  


   .cseg 
   jmp      Main 


Main: 
   ser      r16 
   out      DDRA,r16 

   ldi      r16,0x3f 
   out      PORTA,r16 
   inc      r16 
   out      PORTA,r16   ; <<<<< JTAGICE MKII step fails. "JTAGICE mkII: IDR event 0xff." errors 

   rjmp   PC 

Good luck

jrseattle

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

Ok, they are setting me up with a new Mkii and STK600 as "golden hardware", which I will work with over the weekend. I'll try to replicate this if I can get a "p" or even on my 644, and see if it happens there.

They saw the system giving me the "normal" grade of wierdness. None of the really bizarre stuff, but I was happy. It actually worked fine until about 1:30, then consistently couldn't be used for debugging from then on. :) I was afraid it would sense the FAEs presence, and work properly all day.

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

Well, the FAE visit went well, they dropped off a new Mkii and STK-600, so I will try to duplicate this. I have a 644, not a 644P, but I asked the Arrow guy to get me a couple.

It would be interesting if the default oscillator was off enough that it could interfere with the Jtag.

Anyhoo, I will try to replicate this on my 644, just for grins. If it happens, that would be way interesting.

Yesterday my dev tools (the old ones) worked just fine, so I got a Nokia graphic display up and running, implemented line and box drawing, text, etc.. I'm working twoard a "scope" style display, except that I'll be able to scope things that you can't in the real world, like delta entropy values.

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

Checking here, with a 20 MHz 644, if I set the target frequency to 20 MHz, the pulses on TDO are about 180nS. At 1 MHz target they are 2.10us.

FWIW, changing the target frequency, as long as it is equal to or less than the actual target frequency, hasn't made any noticable difference here in how well studio behaves.