Atmel AVR development tools

[dbvanhorn]

Frustrated, not knowing where to turn with this.

I love the AVR processors. Very clean internally, nice to write code
for.

But, I am on the edge of dumping them due to severe problems with
their dev tools.
Some people seem to have no trouble with them, but I've been having
problems for years, which are inconsistent, unreproducable, and
totally productivity destroying when they happen.

The problems happen mostly in emulation with their ICE-50, Jtag Ice
(and someone's cheap clone) and with their new MkII jtag ice, as well
as their AVRISP chip programmer.

Different computers, including ones freshly scrubbed and rebuilt.
Different processors
Different date codes
Different cables
Different serial or USB ports
Different versions of Studio
Different target boards
Different clock sources, including the internal 1 MHz RC
Different VCC (within spec)

Common threads: XP Pro. AVR Studio (though different versions), Me.

Short version, neither they nor I can figure out WTF is going on.
I've seen it, in the past week, 1: Decide that all my code is NOPs in
sim. 2: Ignore CALL or RCALL instructions. 3: Ignore some LDI
instructions, but not all, just specific ones. 4: Totally refuse to
talk to the target chip with Debugwire. And tomorrow, it will
probably be different.

All that said, for months at a time, everything will be fine.


Any ideas?

 

[Don McKenzie]

Frustrated, not knowing where to turn with this.

All that said, for months at a time, everything will be fine.

crazy,

different locations?

they haven't re-routed the Muncie power grid past your door step
recently, have they Dave?


Don...


--
Don McKenzie

Affiliate Program: http://www.dontronics.com/affiliate
Site Map: http://www.dontronics.com/sitemap
E-Mail Contact Page: http://www.dontronics.com/email
No More Damn Spam: http://www.wizard-of-oz.com

Parallax Propeller Powered .96" OLED module
http://tinyurl.com/2vr2gr

 

[linnix]

Frustrated, not knowing where to turn with this.

I love the AVR processors. Very clean internally, nice to write code
for.

But, I am on the edge of dumping them due to severe problems with
their dev tools.
Some people seem to have no trouble with them, but I've been having
problems for years, which are inconsistent, unreproducable, and
totally productivity destroying when they happen.

The problems happen mostly in emulation with their ICE-50, Jtag Ice
(and someone's cheap clone) and with their new MkII jtag ice, as well
as their AVRISP chip programmer.

Build your own! Since my Jtag Ice's funnel, I have been programming
AVRs with an ARM eval board (programmed as AVR programmer). It's much
more reliable than the Atmel tools. Recently, I am starting to
program AVRs with another pre-programmed AVR. Once programmed, AVR
are very stable.

Common threads: XP Pro. AVR Studio (though different versions), Me.

Dump these as well. I have all the tools avr-gcc and uprog (my USB
programmer) on a 1G CF drive.

 

[JeffM]

Frustrated, not knowing where to turn with this.

ISTM, that you would get a better concentration
of microcontroller-specific knowledge at comp.arch.embedded.

I love the AVR processors.

Goes doubly for http://avrfreaks.net

 

[Adrian Jansen]

Frustrated, not knowing where to turn with this.

I love the AVR processors. Very clean internally, nice to write code
for.

But, I am on the edge of dumping them due to severe problems with
their dev tools.
Some people seem to have no trouble with them, but I've been having
problems for years, which are inconsistent, unreproducable, and
totally productivity destroying when they happen.

The problems happen mostly in emulation with their ICE-50, Jtag Ice
(and someone's cheap clone) and with their new MkII jtag ice, as well
as their AVRISP chip programmer.

Different computers, including ones freshly scrubbed and rebuilt.
Different processors
Different date codes
Different cables
Different serial or USB ports
Different versions of Studio
Different target boards
Different clock sources, including the internal 1 MHz RC
Different VCC (within spec)

Common threads: XP Pro. AVR Studio (though different versions), Me.

Short version, neither they nor I can figure out WTF is going on.
I've seen it, in the past week, 1: Decide that all my code is NOPs in
sim. 2: Ignore CALL or RCALL instructions. 3: Ignore some LDI
instructions, but not all, just specific ones. 4: Totally refuse to
talk to the target chip with Debugwire. And tomorrow, it will
probably be different.

All that said, for months at a time, everything will be fine.


Any ideas?

I too have very occasionally seen the code display in AVR studio show
silly things for the LDI instruction, usually LDI &h00 when it should be
a non-zero. Also seen LDS &h0000 when it should be a valid RAM address.
But the code seems to execute ok in a target system. Never tried it
in the simulator. Use both JTAG ICE MkII and a USB version of the MkI.
Suspect its actually a problem in AVR Studio itself, not in hardware.

As you say, its not consistent, but I never saw it often enough to cause
a serious problem. My 'fix' is to go on and develop some more code,
then when I come back to the debugger, the problem has gone away. Some
fix !

System here is Windoze 2000 SP 2 and AVR Studio 4.12 SP 4.


--
Regards,

Adrian Jansen adrianjansen at internode dot on dot net
Design Engineer J & K Micro Systems
Microcomputer solutions for industrial control
Note reply address is invalid, convert address above to machine form.

 

[dbvanhorn]

crazy,

different locations?

Southern Georgia, Vancouver, Pittsburgh, Muncie, Indianapolis,
Philadelphia and Baltimore come to mind.

they haven't re-routed the Muncie power grid past your door step
recently, have they Dave?

Nope.

 

[dbvanhorn]

ISTM, that you would get a better concentration
of microcontroller-specific knowledge at comp.arch.embedded.


Goes doubly forhttp://avrfreaks.net

Unfortunately, S+N/N << 1

 

[dbvanhorn]

I too have very occasionally seen the code display in AVR studio show
silly things for the LDI instruction, usually LDI &h00 when it should be
a non-zero.  Also seen LDS &h0000 when it should be a valid RAM address.
  But the code seems to execute ok in a target system.  Never tried it
in the simulator.  Use both JTAG ICE MkII and a USB version of the MkI.
  Suspect its actually a problem in AVR Studio itself, not in hardware.

Me too, and I suspect they aren't putting much heat on it because it's
a "free" tool, nevermind how essential it might be to getting things
done.

As you say, its not consistent, but I never saw it often enough to cause
a serious problem.  My 'fix' is to go on and develop some more code,
then when I come back to the debugger, the problem has gone away.  Some
fix !

Right, this is the sort of thing that I have going on.

 

[Vladimir Vassilevsky]

Frustrated, not knowing where to turn with this.

I love the AVR processors. Very clean internally, nice to write code
for.

Nice and fast core but poor set of the peripherals.

But, I am on the edge of dumping them due to severe problems with
their dev tools.

The biggest problem is that Atmel keeps dropping and changing the AVR
lines. That makes the AVR unsuitable for the long term projects.

Some people seem to have no trouble with them, but I've been having
problems for years, which are inconsistent, unreproducable, and
totally productivity destroying when they happen.

The problems happen mostly in emulation with their ICE-50, Jtag Ice
(and someone's cheap clone) and with their new MkII jtag ice, as well
as their AVRISP chip programmer.

Why do you need that?

The only tools I ever used for AVR are the scope, the byteblaster and
the debug printout to RS-232. I developed the projects of up to about
20k lines of C++ code and the home made RTOS.

Short version, neither they nor I can figure out WTF is going on.

Apparently the problem is with you.

I've seen it, in the past week, 1: Decide that all my code is NOPs in
sim. 2: Ignore CALL or RCALL instructions. 3: Ignore some LDI
instructions, but not all, just specific ones. 4: Totally refuse to
talk to the target chip with Debugwire. And tomorrow, it will
probably be different.

All that said, for months at a time, everything will be fine.

Any ideas?

You have to stop playing games with the fancy toys and content yourself
with the essential.
The entities should not be multiplied beyond the necessity.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

 

[dbvanhorn]

Build your own!  Since my Jtag Ice's funnel,
Funeral?

I have been programming
AVRs with an ARM eval board (programmed as AVR programmer).  It's much
more reliable than the Atmel tools.  Recently, I am starting to
program AVRs with another pre-programmed AVR.  Once programmed, AVR
are very stable.

I've used other "clone" Jtag ices, with the same reliability problems.

Dump these as well.  I have all the tools avr-gcc and uprog (my USB
programmer) on a 1G CF drive.

One of these days, I may have to start using C, but I've been avoiding
it.
It seems to add yet another layer (or two) of possible problems, as
well as sucking up system resources and cycles. And it wouldn't
remove me from the need to run in sim or emulation.

 

[dbvanhorn]

Why do you need that?

The only tools I ever used for AVR are the scope, the byteblaster and
the debug printout to RS-232. I developed the projects of up to about
20k lines of C++ code and the home made RTOS.

I hear ya. I have in the past, done "crash and burn" with only single
pin output of many bytes of data.
It's error-prone and tedious, but it does work. The additional code
to output the debugging data takes time and space too though, and I
don't always have that spare.

Apparently the problem is with you.

Yeah. I'm leaning twoard Studio using some memory somewhere
that's not initialized.
That's sure what it feels like.

You have to stop playing games with the fancy toys and content yourself
with the essential.
The entities should not be multiplied beyond the necessity.

This would be the second time I've heard someone tell me to just ditch
the Atmel toolchain entirely.
Maybe I'm just stuck because it USED TO WORK. It worked flawlessly. I
delivered apps one after the other, and NEVER had to worry wether a
tool would work. The sim was great, and very useful. Their ICE-200
was wonderful. The ICE-50 was great, up till the first official
release, then it went to hell.

 

[linnix]

Funeral?

Oh, yes. My poor spellings.

I've used other "clone" Jtag ices, with the same reliability problems.

The AVR debug core is unreliable, jtag or non-jtag. SPI programming
is much more reliable. Also, avoid bootloaders.

One of these days, I may have to start using C, but I've been avoiding
it.
It seems to add yet another layer (or two) of possible problems, as
well as sucking up system resources and cycles. And it wouldn't
remove me from the need to run in sim or emulation.

I know I am not a normal user, but learned to live with the essentials
only, as another poster suggested.

I used the Jtag Ice long enough to develop a set of usable library,
mostly serial port and LED/LCD drivers. After that, I have not use
any simulator/emulator at all. But I am only doing a simple project
of 2000 lines / 8K at most. We will be building thousands of them, so
a simple compiler and isp loader is more important than fancy
simulator.

 

[Martin Griffith]

I hear ya. I have in the past, done "crash and burn" with only single
pin output of many bytes of data.
It's error-prone and tedious, but it does work. The additional code
to output the debugging data takes time and space too though, and I
don't always have that spare.


Yeah. I'm leaning twoard Studio using some memory somewhere
that's not initialized.
That's sure what it feels like.



This would be the second time I've heard someone tell me to just ditch
the Atmel toolchain entirely.
Maybe I'm just stuck because it USED TO WORK. It worked flawlessly. I
delivered apps one after the other, and NEVER had to worry wether a
tool would work. The sim was great, and very useful. Their ICE-200
was wonderful. The ICE-50 was great, up till the first official
release, then it went to hell.

Just had the same problem, I downloaded the latest GCC/studio4 stuff,
but the thinkulator would not run :

"AVR Simulator: Invalid opcode 0xffff at address 0x00f000"

on a "helloworld.c", but simpler

While(1)
{
counter++;
}

It worked on a 1 year old "not updated" setup on my laptop.

MSP430 anyone?


martin

 

[Marco Trapanese]

...but poor set of the peripherals.

However better than PICs. What other 8-bit uC do you have in mind?


Marco / iw2nzm

 

[Jamie]

Frustrated, not knowing where to turn with this.

I love the AVR processors. Very clean internally, nice to write code
for.

But, I am on the edge of dumping them due to severe problems with
their dev tools.
Some people seem to have no trouble with them, but I've been having
problems for years, which are inconsistent, unreproducable, and
totally productivity destroying when they happen.

The problems happen mostly in emulation with their ICE-50, Jtag Ice
(and someone's cheap clone) and with their new MkII jtag ice, as well
as their AVRISP chip programmer.

Different computers, including ones freshly scrubbed and rebuilt.
Different processors
Different date codes
Different cables
Different serial or USB ports
Different versions of Studio
Different target boards
Different clock sources, including the internal 1 MHz RC
Different VCC (within spec)

Common threads: XP Pro. AVR Studio (though different versions), Me.

Short version, neither they nor I can figure out WTF is going on.
I've seen it, in the past week, 1: Decide that all my code is NOPs in
sim. 2: Ignore CALL or RCALL instructions. 3: Ignore some LDI
instructions, but not all, just specific ones. 4: Totally refuse to
talk to the target chip with Debugwire. And tomorrow, it will
probably be different.

All that said, for months at a time, everything will be fine.


Any ideas?

simple solution, get a computer with a real RS-232 port on it, and use
that option, using RS-232 converters or direct USB I find is unreliable
not just for that process but for other things that really need the
attention of the PC also.
I Also find that when I used older versions of windows I have much
better luck .. 98/W2k is what I normally use for programming the units.

 

[Vladimir Vassilevsky]

The 16-bit timer of AVR is handy. I wish there could be 3 or 4 timers
like that.

However better than PICs.

I am not familiar with the latest AVRs and PICs. PIC peripheral offering
used to be far superior to that of AVRs, and I guess it still is.

What other 8-bit uC do you have in mind?

The HC12 family.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

 

[linnix]

The 16-bit timer of AVR is handy. I wish there could be 3 or 4 timers
like that.




I am not familiar with the latest AVRs and PICs. PIC peripheral offering
used to be far superior to that of AVRs, and I guess it still is.


The HC12 family.

Vladimir Vassilevsky
DSP and Mixed Signal Design Consultanthttp://www.abvolt.com

Not exactly 8 bits, but who care. What about the coldfire
MCF51QE128? Price is within our budget, for 2 pennies each. Perhaps
with another 49 pennies for silicons.

 

[Vladimir Vassilevsky]

linnix wrote:

Not exactly 8 bits, but who care.

It is marketed as 16-bitter however it looks no different from the old
good 68xx. In HC12 there is even no penalty for the misalignment.

What about the coldfire
MCF51QE128?

Good one. Thank you for the tip.

Price is within our budget, for 2 pennies each. Perhaps
with another 49 pennies for silicons.

Well definitely not worse then the big Mega AVRs.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

 

[T]

The 16-bit timer of AVR is handy. I wish there could be 3 or 4 timers
like that.


I am not familiar with the latest AVRs and PICs. PIC peripheral offering
used to be far superior to that of AVRs, and I guess it still is.

The Atmel ATMega168 is used in all the Arduino based platforms. I use
Processing as the IDE.

 

[Frithiof Andreas Jensen]

Maybe I'm just stuck because it USED TO WORK. It worked flawlessly. I
delivered apps one after the other, and NEVER had to worry wether a
tool would work. The sim was great, and very useful. Their ICE-200
was wonderful. The ICE-50 was great, up till the first official
release, then it went to hell.

The way of all software. It gets "improved" until it sucks so much that
nobody will use it. Then Symantek buys it and sell it under another label
for another round of grief ;.)