Anyone actually using AVaRice?

Go To Last Post
62 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In another thread regarding AS5, the discussion touched OCD possibilities other than Atmels closed software.

I have had some interest in this topic to and fro, and that thread woke it up again.

I am aware of the existence of AVaRice, but know no details. I am also a definitive rookie when it comes to stuff like GDB. I'd like to learn more. So..

Is anyone here actually using AVaRice?

On Windows?

Do you know if the AVaRice project is actually alive?

Does AVaRice still require Cygwin?

The AVaRice webpages seems to suggest that it supports JTAGICE only, but the WinAVR documentation seems to suggest it supports JTAGICE mkII. What is true?

.. and most likely a bunch of other questions that I can not even formulate yet.

Any help or insight shared is highly appreciated!

/While this is not avr-gcc per se, I placed this post in this forum as it is closely related to the avr-gcc toolchain. If a moderator thinks differently, feel free to move it.)

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

I have always assumed that Rowley is based on GCC. They have their own formats for the objects etc.

I would guess that the debugging facilities will be based on GNU source code.

OTOH, I am not aware of any Rowley licence holders on AvrFreaks.

I have asked exactly the same question several times. "Does anyone regularly use the GNU tools for debugging?"

If they do, is it a practical alternative to Studio or IAR?

My brief trial of Rowley a couple of years ago would say: CrossStudio works very well with real JTAG, but did not Simulate as effectively as Studio.

David.

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

For a start (even using the DOS versions!) read Colin O'Flynn's article:

http://winavr.sourceforge.net/AVR-GDB_and_AVaRICE_Guide.pdf

also see:

http://www.larsen-b.com/Article/...

As Colin notes it's useful to run "avarice --help" to see anything more recently added. This reveals, for example, --dragon and --debugwire so it's more up to date than the last time I looked at it ;-)

To be honest I don't see the point of using the tools on Win32 when AVR Studio (the good one!) exists? Clearly on Linux (apart from wine or a VM) then you get little choice in the matter. (I do like ddd with gdb though)

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

Quote:

To be honest I don't see the point of using the tools on Win32 when AVR Studio (the good one!) exists?

1. As you know, "the good one" crashes for me.

2. I am playing in my mind with a setup that is similar on different platforms.

3. While IMO better than AS5, AS4 also has deficiences. Version control support, modern editor, refactoring etc, intellisense etc. It would be interesting to see how far one can get with something else.

4. I've been temped to lean heavier on GNU/Linx and less on Windows, so I am also interested in OCD possibilities on e.g. Ubuntu.

I'm just surveying right now, trying to understand "the lay of the land". Sorry if I sound unstructured or confused - that's probably because I am...

Your apropos re the Dragon in AVaRice sounds interesting. I'll read those things you linked to!

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

Johan,

Evaluate Rowley. It will run on Windoze or Linux or Mac. If you are happy with it, a hobbyist licence is only $150. (Eductational is $300, Commercial is $1500)

I have no problem paying for a CodeVision licence even as a hobbyist. I also have a Rowley ARM hobbyist licence.

Think about it. $150 is money well worth paying compared to your time wasted with AS5.

David.

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

Yes, Rowley might be a way David. (But I want to have the option to move freely between platforms, and then I suppose I'd have to pay for one license per platform. Will investigate.)

Cliff! Thank you for the links. The article by Larsen is really interesting, and it implies that the Dragon is supported. This has to be tested.

And I suppose that if a GDB solution/"stack" works with DDD then it should work with e.g. the GDB plugin for Eclipse? Or even in NetBeans? (Am I making a bad/bold assumption here?)

What worries me is that I have seen nothing re debugWire in any AVaRice writings..

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]

Last Edited: Wed. Aug 31, 2011 - 10:30 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AVARIce is a software driver for some AVR dongles.
AFAIK it can be applied to several of those(that is what doc says). It does programming and debugging (and perhaps boundary scanning with JTAG but I am not 100% sure about that capabilities), although with some limitations (wrt Atmel's original tools).

Anyway, of the three modes you are interested in OCD?

I (several times!)used AVARice with JTAG ICE Mk1 clone on Windows XP (m16,m162,m128).
- pros are programming works seamlessly
- cons are talking to OCD does not support more sophisticated commands, like hardware breakpoints+range, break on program flow, software breakpoints, I am not sure about running timers with halted core etc.. AS4 does support those.

AVRInsight is good for the start. It is much more "rough" than AS, but usable GUI.

Quote:
As you know, "the good one" crashes for me.

AS4.18? Could you post a link to where you described your problem?

Quote:
Does AVaRice still require Cygwin?

Why do you think it matters? Are you worried about the speed? Works same as AS for me. Perhaps even bit faster.

Quote:
"Does anyone regularly use the GNU tools for debugging?"

Rather "why aren't you using GNU tooling?"

1. Because of proprietary OCD and features these tools do not support. Not much to be done in here, although I have head of several attempts of reverse-engineering :)
2. Eclipse does not have an IO register view!
3. AS4 is "acceptable" for now.

No RSTDISBL, no fun!

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

Quote:

Quote:
Does AVaRice still require Cygwin?

Why do you think it matters? Are you worried about the speed? Works same as AS for me. Perhaps even bit faster.


Because eery time I've been confronted with Cygwin it has been a rotten experience. E.g. the Cygwin people invented their own version of the DLL hell. I have decided that Cygwin is one of the things that I will not touch with a 10" pole if I can avoid it. (Cf. e.g. WinAVR that in large parts do not depend on it any more, but instead uses MinGW.)

Quote:
AS4 is "acceptable" for now.

Not for me anymore, for reasons stated above.

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

Are you planning to build it or to use AVARice? If the latter - cygwin1.dll is already included in WinAVR package.

The only thing that made problems are tiny, annoying small differences.

UNIX uses "/dev/com1" names rather than "com1" when referencing serial ports..

Try AVARIce + Insight. And then move to Eclipse perhaps.

JohanEkdahl in mentioned topic wrote:
it crashes violently whenever I stop debugging

I do remember AS4 crashes sometimes.. Not too often, but it does, when starting or quitting debug session.

No RSTDISBL, no fun!

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

Quote:

Not too often, but it does

Every time for me. Without exception.

Quote:

cygwin1.dll is already included in WinAVR package.

The only thing that made problems are tiny, annoying small differences.


As I understand it, cygwin1.dll has been distributed under the same name but with different interfaces. So whenever two different softwares brings two different cygwin1.dll's to a machine then it is highly likely that one of them will stop functioning. I would not call that "annoying" or "small".

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

> Is anyone here actually using AVaRice?

Yes, me, obviously. ;-)

> On Windows?

Nope. "In a world without walls and fences, who needs gates and
windows?" :)

> Do you know if the AVaRice project is actually alive?

More or less, yes.

> Does AVaRice still require Cygwin?

Yes, since it's been written ground up with the Posix API in mind, so
this is not easy to change. Unlike AVRDUDE (which only needs to
distinguish between Posix and Win32 APIs when it comes to talk to
serial lines), AVaRICE requires multiplexed IO channels (it has to
talk to both, the ICE as well as GDB), and for USB, it also requires a
slave process (internally dubbed "USB daemon") to handle the libusb
communication. Both these cannot easily be replaced with Win32
counterparts without redesigning a lot of code around that.

> The AVaRice webpages seems to suggest that it supports JTAGICE only,
> but the WinAVR documentation seems to suggest it supports JTAGICE
> mkII. What is true?

JTAGICEmkI (though support for it might bit-rot over time),
JTAGICEmkII, AVR Dragon. Both of the latter are supported in JTAG as
well as debugWIRE mode. Basically all of the things Brutte complained
about of for the JTAGICEmkI are no longer an issue for the
mkII/Dragon.

There's no option to have timers running while CPU is stopped, as
nobody has ever been asking for that.

There's one really cool thing though AVR Studio IMHO doesn't offer:
ignore code running in ISRs when single-stepping. It's slow (as the
breakpoint would still hit, and cause traffic between AVaRICE and the
JTAGICE, but all this is hidden from the debugger), but it works.
There used to be another feature unique to AVaRICE, in that you could
attach it to a running firmware without causing a CPU reset (so to
debug a long-running application that got stuck or such), though I've
heard AVR Studio eventually implemented that, too.

There's almost no support for Xmegas due to lack of documentation, and
lack of people who would reengineer the undocumented parts, albeit
there has been a mailinglist message last week from someone who
started to reengineer Xmega debugging with the new (AVR Studio 5.x)
firmware.

On the JTAGICEmkII or Dragon, "live" firmware upgrades (from within
the debugger) don't really work, you have to make a round-trip through
AVRDUDE for that. This feature did work with the JTAGICEmkI,
apparently since that device managed the flash page assembly by
itself, but the mkII doesn't (and GDB spits out its memory write
commands in some kind of unpredictable manner, having no resemblance
to page sizes or such since it doesn't know what a paged memory would
be).

> As I understand it, cygwin1.dll has been distributed under the same name but with different interfaces.

As I understand it, there's no support for versioned shared libraries
in Windows (so several versions with incompatible APIs could coexist,
and each application picks "her" version), so you might blame someone
in Redmond for that.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

Last Edited: Wed. Aug 31, 2011 - 11:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Easiest answer is to put the cygwin1.dll that comes with WinAVR in the same directory as avarice.exe as that will be searched first as the .exe is loaded before the DLL hunt heads off down your PATH.

As it happens Eric thought of this and both are already in \Winavr20100111\bin\

Cliff

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

Jörg! Thank you so very much for those answers - you are an indispensable and always flowing fountsin of knowledge! :D

The Dragon and debugWire facts above are assuring - I will try to reserve some time for testing this ASAP. Wether it initially will be on Windoze or Ubuntu remains to be decided..

Quote:

On the JTAGICEmkII or Dragon, "live" firmware upgrades (from within
the debugger) don't really work, you have to make a round-trip through
AVRDUDE for that.

I read this as me having to
1. Disable debugWire (can AVaRice+GDB do that??!)
2. Use AVRdude in ISP mode to program the new firmware.
3. Use AVRdude to enable debugWire
4. Start debugging with AVaRice+GDB.
Correct?

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

Meanwhile, I have just purchased a hobbyist licence for Rowley. (I have always had an ARM licence)

I will report back on my experience.
It will be useful to compare with Studio5.

Of course a Commercial licence is relatively expensive.

My memories of evaluating it two years ago are clouded. 30 days runs out pretty quick. But it will be interesting to see how well it works with non-AVR JTAG debuggers.

David.

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

dl8dtl wrote:
AVaRICE requires multiplexed IO channels (it has to talk to both, the ICE as well as GDB

IMHO Cygwin is not a requirement - it just simplifies development/porting it seems.
OpenOCD serves exactly the same purpose and can be built for many platforms.

dl8dtl wrote:
Basically all of the thing Brutte complained (..)are no longer an issue for the mkII/Dragon.

Except for the price of the dongles :)

dl8dtl wrote:
There's no option to have timers running while CPU is stopped, as nobody has ever been asking for that.

What about asm(break), hardware data/program breakpoints with mask?
dl8dtl wrote:
ignore code running in ISRs when single-stepping.

Let me guess - it reads out PC at single stepping and if that changed for the one from ISR code, sets breakpoint on the main() instruction waiting for the reti..
Nice, although it is not supported by OCD - it is emulated on a PC side (changes timings).
dl8dtl wrote:
There used to be another feature(..)though I've heard AVR Studio eventually implemented that, too.

Never tried that option on AS. I imagine a customer sends you a crashed AVR, but still "breathing", and you inspect what is going on, when it is still alive :)

dl8dtl wrote:
There's almost no support for Xmegas due to lack of documentation,

http://lura.sk/?&LP=114SK&MP=4&M...
Never tried that.

http://openocd.berlios.de/web/ wrote:

preliminary AVR32 AP7000 support

Quote:
albeit there has been a mailinglist message last week from someone who started to reengineer Xmega debugging with the new (AVR Studio 5.x) firmware.

Can you give some details (link)? Perhaps there is a chance to make all this work as a single AVR dongle driver supporting many AVRs?

No RSTDISBL, no fun!

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

Quote:
albeit there has been a mailinglist message last week from someone who
started to reengineer Xmega debugging with the new (AVR Studio 5.x)
firmware.

This seems to imply two things:

1) There is activity on the AVaRice mailing list. Great! I will subscribe.

2) The current AVaRice wants the older Dragon firmware that goes with AS4. Am I correct in this assumption? (Because if so, I will need to downgrade the firmware before testing.)

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

Johan,

See around line 461 onwards:

http://avarice.cvs.sourceforge.n...

It only seems to be checking the firmware version to know the structure of the packets.

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

CrossWorks for ARM is the only Rowley compiler that uses gcc (they developed their own libraries). They created their own compilers for the MSP430, AVR and Maxim chips.

Leon Heller G1HSM

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

The question is not about the compilers but the debug tools - does CrossWorks for AVR have direct support for JTAGICE, JTAGICEmkII, JTAGICEmkIII, Dragon and AVR One! Doing any/all of JTAG, debugWire, PDI ?

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

Brutte wrote:

>> AVaRICE requires multiplexed IO channels (it has to talk to both,
>> the ICE as well as GDB

> IMHO Cygwin is not a requirement - it just simplifies
> development/porting it seems.

*Given the current design* of AVaRICE, it's a requirement.

Remember, this all started out more than 10 years ago in order to get
people who don't want to use Windows something they could use.
Windows users were always provided by Atmel with tools (and told to
use IAR when they asked for a compiler), but !Windows users didn't get
anything, so they started to write their own tools.

Consequently, it's not surprising those tools have been written from
the point of view of a Posix programming paradigm. At all times,
there have not been too many developers contributing who worked under
Windows systems (the person contributing the Win32 API serial code to
AVRDUDE is one of the notable exceptions).

Yes, using a different design, it could be done otherwise. However,
as far as I can see, I'm almost the only active (well, to some degree
at least ;) developer on AVaRICE, and I've got neither time nor
motivation for a full-layer redesign. I don't want to use Windows
myself (simply because, whatever I'm trying to do with it, I'm getting
the impression the OS is more sitting in my way rather than helping me
getting the job done), so sorry, *I* am simply not the one who would
start a rewrite just to get decent Windows support into it. If that
person should ever exist, it probably has to be someone who is
passionate to do his development work under Windows.

>> Basically all of the thing Brutte complained (..)are no longer an
>> issue for the mkII/Dragon.

> Except for the price of the dongles Smile

IIRC, the price of the Atmel JTAGICE has always been the same. ;-)

Yes, the mkII cannot be that easily cloned, and even though I believe
a clone does exist meanwhile, it has a hard time competing with the
AVR Dragon.

> What about asm(break), hardware data/program breakpoints with mask?

What would you want to use asm(break) for?

I've got no idea what will happen. My guess is it will simply confuse
the ICE, which notices the break instruction but cannot find a
breakpoint for it, so it will likely pass the break event up to the
debugger. If the reported $PC value has not been advanced to point
behind the BREAK instruction, it will break immediately again if you
continue. Manually bump $PC in the debugger to go on then.

Data breakpoints have been working for many years now on the mkII (I
think the mkI hardware didn't support them at all), limited to the
constraints the AVR hardware imposes (they have to fit into a
base_address + mask schema, but since the AVR architecture doesn't
require the compiler to align data, for any data larger than 8 bits,
it's not ensured they could be expressed as a base_address + mask).

Software breakpoints have been supported for more than four years now.
I usually avoid them because I think they were slow (given the ICE has
to reprogram flash pages for them), but whenever I see the quite
decent debugging speed debugWIRE gets up to (which offers no hardware
breakpoints at all), I have to confess they aren't that slow,
actually.

>> ignore code running in ISRs when single-stepping.

> Let me guess - it reads out PC at single stepping and if that
> changed for the one from ISR code, sets breakpoint on the main()
> instruction waiting for the reti..

Something like that, probably. I never tried to understand the
details, that code has still been written by Ted Roth, who has been
maintaining most of these tools before me.

>> There's almost no support for Xmegas due to lack of documentation,

> http://lura.sk/?&LP=114SK&MP=4& ... ;PO=%27%27
> Never tried that.

Doesn't appear to support Xmegas either though. Still, impressive,
given that the low-level JTAG debugging of megaAVR isn't documented
either (not to be confused with the megaAVR JTAGICE debugging
interface that is documented in AVR067).

> http://openocd.berlios.de/web/ wrote:
>
> preliminary AVR32 AP7000 support

I guess AVR32 took a different route, so their entire JTAG interface
might be documented. I've never been looking. I only see the JTAG
ICE's firmware got new "JTAG passthrough" commands added to support
the AVR32, as the 8-bit AVR Studio model simply did not fit for them.

>> albeit there has been a mailinglist message last week from someone
>> who started to reengineer Xmega debugging with the new (AVR Studio
>> 5.x) firmware.

> Can you give some details (link)?

https://sourceforge.net/mailarch...

I haven't replied yet, because I wanted to ship AVaRICE 2.11 first,
before digging into what he wrote.

Johan Ekdahl wrote:

> This seems to imply two things:

> 1) There is activity on the AVaRice mailing list. Great! I will
> subscribe.

Well, fairly low activity, unfortunately. I always wish some more
people would contribute ...

> 2) The current AVaRice wants the older Dragon firmware that goes
> with AS4. Am I correct in this assumption? (Because if so, I will
> need to downgrade the firmware before testing.)

Well, it has only been tested with the older firmware version that
shipped with AVR Studio 4.x, except by Detlev Kraft (the guy who wrote
the mailinglist article mentioned). So far, he's the first one who
approached me and told me he were using a firmware based on AVR Studio
5. Given what Detlev wrote, it seems there are some differences in
the way AVR Studio 5 handles the ICE, compared to version 4.

However, it's quite possible that the firmware is backwards compatible
enough to not cause any problems for tinyAVR/megaAVR devices, I just
can't tell you. Detlev's problems were only related to Xmega
debugging, but that has not been working at all with the older
firmware, since the entire breakpoint handling for Xmegas was
*completely* different than that of megaAVRs, and (as mentioned), all
this has never been documented by Atmel.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

clawson wrote:
The question is not about the compilers but the debug tools - does CrossWorks for AVR have direct support for JTAGICE, JTAGICEmkII, JTAGICEmkIII, Dragon and AVR One! Doing any/all of JTAG, debugWire, PDI ?

That question about gcc was asked earlier in the thread, and wasn't answered.

Leon Heller G1HSM

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

Quote:
Yes, using a different design, it could be done otherwise.

Misunderstanding. I didn't say Cygwin is good or bad. From earlier posts I just infered Cygwin is a must because of AVR<->GDB double sided communication.
I believe POSIX API is fine, Cygwin does the job and I do not see the point to port such software (which is not a RealTime application) to Windows API.

Quote:
IIRC, the price of the Atmel JTAGICE has always been the same. ;-)

What I wanted to say is JTAGICE MKx is dumber than FT232H chip worth 3$, but is bought for 300$ only because of AVRs proprietary debug protocol.

Quote:
I haven't replied yet, because I wanted to ship AVaRICE 2.11 first, before digging into what he wrote.

HappyJTAG2 works with XMega128A1. On Windows.

Quote:
since the entire breakpoint handling for Xmegas was *completely* different

It is also completely different from low level JTAG perspective(different register locations). XMega OCD has different capabilities comparing with Mega JTAG OCD (and poor dW OCD - not to mention).

Did anybody from Avarice Project considered combining forces with OpenOCD for example? I am not insisting on debugging ARM11 with Dragon, but it would be nice to use FT232H (or other OpenOCD dongles) with AVRs and GDB..

No RSTDISBL, no fun!

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

> What I wanted to say is JTAGICE MKx is dumber than FT232H
> chip worth 3$, but is bought for 300$ only because of AVRs
> proprietary debug protocol.

Actually, the JTAG ICE mkII is indeed a lot smarter than that, don't
underestimate this. But: it's not really needed for GDB. AVR Studio (4)
simply approached the entire debugging job on a completely different
path, and offloaded a good number of things into the JTAG ICE.

> Did anybody from Avarice Project considered combining forces with OpenOCD
> for example?

Nope, but I think OpenOCD simply is a different path to go. AVaRICE
(and its developers) never even tried to analyze the low-level JTAG (or
debugWIRE) protocol, so there's no knowledge around (among them) to
integrate it into OpenOCD.

> I am not insisting on debugging ARM11 with Dragon, but it would be
> nice to use FT232H (or other OpenOCD dongles) with AVRs and GDB..

Sure. It will likely be a lot faster, too (even on FTDI chips without
the "H", only the MPSSE is needed).

> and poor dW OCD

Well, debugWIRE is an astonishingly well-working compromise for
small devices, I must say. I've been sceptic at first, too.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Quote:
Meanwhile, I have just purchased a hobbyist licence for Rowley.

David

What is 150 bucks in real money?

I've just installed the evaluation version for Mac OS X. It's Visual Studio by any other name! Just not half a gig's worth of it :)

Now, if the debugger works as advertised, I might be tempted away from Eclipse and GCC...

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

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

The Rowley IDE and debugger are excellent. I've been using their tools for years for MSP430 and ARM development under Windows.

Leon Heller G1HSM

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

Quote:
development under Windows
and there was me thinking you were being serious... then you go and ruin it :twisted:

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

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

Johan wrote:

> I read this as me having to
> 1. Disable debugWire (can AVaRice+GDB do that??!)
> 2. Use AVRdude in ISP mode to program the new firmware.
> 3. Use AVRdude to enable debugWire
> 4. Start debugging with AVaRice+GDB.
> Correct?

...and I forgot to answer this.

Basically, yes, that's the steps. But, it's not AVaRICE to disable
debugWIRE but AVRDUDE itself. It's really simple to do it: you just
issue the *ISP* command you intend to apply. AVRDUDE notices it can't
initialize ISP, and if the AVR part is a debugWIRE one, it will then
attempt to disable debugWIRE, and exit. Then, you issue the very same
command again (which is just , in the shell), and
it should work. Disabling and reinitiating the JTAG ICE session is
mandated that way by Atmel (though someone once reported to me he
could get away without it), and this is just a temporary thing: by
temporarily disabling debugWIRE on the /RESET pin, that pin is
available for ISP again. You don't necessarily have to touch the DWEN
fuse: ISP will remain possible until you power cycle the target (and
there's no way around that power cycle, not that I knew of). On the
next power-on reset, the DWEN fuse will be re-examined, and if it's
still enabled, you can attach the debugger (or AVaRICE, respectively)
again. If, during the ISP session, DWEN got disabled, your chip will
be back to normal life.

Though, this cumbersome cycle is not strictly necessary. AVRDUDE also
knows how to download a flash image through debugWIRE, so you don't
have to cycle between dW and ISP mode at all. Alas, in my experience,
debugWIRE downloading is a little slower (probably not a big deal for
those small devices), and the debugWIRE protocol is less robust than
the ISP protocol.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Quote:
Actually, the JTAG ICE mkII is indeed a lot smarter than that, don't underestimate this.

I hope you do not underline it is a swiss-knife and because of that it is worth the price. I wonder how many proprietary protocols Atmlel should introduce in their products to make it worth 1000$ :)

I just do not understand what can be made smarter than banging TCK. It is just shifting commands in and out.. Is it faster than Wiggler? More reliable? Cheaper perhaps? More flexible?

Quote:
and offloaded a good number of things into the JTAG ICE.

So Atmel decided to offload my CoreDuo 2x2GHz + Hi-Speed 480Mb USB making a "smart" AVR dongle for 300$? Customers (and Freaks) are delighted.

Quote:
never even tried to analyze the low-level JTAG
Unfortunately. This project spins up Atmel's proprietary debug protocol policy.
Mind I didn't post you are bad, that you are doing something horrible or that you should be ashamed. It is just that what you do does not go with your karma:
dl8dtl wrote:
"In a world without walls and fences, who needs gates and windows?"

Quote:
Well, debugWIRE is an astonishingly well-working compromise for small devices, I must say. I've been sceptic at first, too.
I have never understood what dW is targeting actually. A hobbyst does not care if the chip costs 2$ or 4$(unless a "bad luck" happens), so what is the point buying poor and small pin count chip? Mass production is ROM and/or OCD-less. Somewhere in between there is a niche for tiny chip with OCD, but can be completely substituted with a set of compatible "older sister with JTAG" during Debug and cheap tiny in Release. Works great with AVRs. Anyway, the same happens with SWD/JTAG of ARMs so it seems that dW/JTAG is a necessity.

No RSTDISBL, no fun!

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

Quote:

to make it worth 1000$

AVR One! = $599 ;-)
Quote:

I have never understood what dW is targeting actually

Not using up 4 pins when the chip only has 28 or less.

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

clawson wrote:
The question is not about the compilers but the debug tools - does CrossWorks for AVR have direct support for JTAGICE, JTAGICEmkII, JTAGICEmkIII, Dragon and AVR One! Doing any/all of JTAG, debugWire, PDI ?

I will give you a definitive answer later. It appears to support mkII and Dragon in all modes. The mkI in JTAG mode. Their own CrossConnect JTAG. The conventional Wiggler.

I have a Wiggler, so I can try it sometime.
If they support a LPT Wiggler, they should be able to support an FTDI JTAG. But they are quiet about that.

There is no mention of AvrOne or mk3. I would guess that only the mkII and Dragon do debugWire.

Quite honestly, I like the IDE. It is identical to the ARM version. Until I find a problem with the Compiler or Debugger, everything looks lovely.

Likewise, I will put the Simulator to the test. I now remember why I did not buy the licence two years ago.

You cannot debug Rowley executables with Studio. (or could not then)

David.

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

Quote:
AVR One! = $599

Actually that 1k$ was supposed to be an example of ridiculous dongle pricing achieved with the support of proprietary protocols policy. AVRTwo! hits 899$ for sure. Ok, should 2k$ be ridiculous enough?

Some day AVARice will enlist those in "supported dongles" chapter.

Quote:
Not using up 4 pins when the chip only has 28 or less.

Chip does not come with 28 pins, but exactly as many as you pay for. What I meant is who is going to buy those dW low pin count chips for hobby or small volume project? You do not have /RESET, you cannot set hardware PC breakpoints. Each break modification means reloading flash. Not mentioning there are no data breakpoints at all!

These (and OCD-less) were made to entertain Freaks, to provide "debugging with challenges" option (DWC!).
Why to use these chips when you are someone like me - a person who has other more interesting challenges to overcome than fighting with small pin count and lack of OCD?

No RSTDISBL, no fun!

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

But what about Ford, Apple or Sony who want to buy 10million mega88's? Are you saying that Atmel have to provide them a special variant with OCD to do their development work? Or are you suggesting they develop without the support of OCD?

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

Quote:
But what about Ford, Apple or Sony who want to buy 10million mega88's?

This is a mass production sector >1e4. Reference please.
Quote:
Or are you suggesting they develop without the support of OCD?

I am saying a reasonable Freak will not bang its head against a wall with m8 (Freaks sector, <1e2 a year) and for somebody placed in between it is much faster and much more reliable to do Debug version on something with OCD. As peripherals and cores of AVRs fit, it is usually enough to set one #define to switch from "older sister" to cheap Release chip in most cases.

Now, mass production is a specific market and I do not think flash 8-bitters can find a place in there (unless some special requirements apply).

Anyway, considering digikey pricings, I do not understand why to play with m88 at all(that is another story) at that quantities:

http://search.digikey.com/script...

http://search.digikey.com/script...

No RSTDISBL, no fun!

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

I think he is suggesting that we go back to the days of special bond-out chips for development. I would guess that someone has had too much vodka.

If a manufacturer can fit an OCD block into a chip, why ever not?

The alternative is to have two versions of each chip. The non-OCD that is dead cheap. The OCD bond-out version that sells in singles and costs $100s.

I quite agree with developing on a bigger chip and down-sizing for production. All the same, people are much happier doing the final debug and test on the target chip.

David.

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

Quote:
I quite agree with developing on a bigger chip and down-sizing for production.
Quite right. +1 vote :)

David: have you the same 'int debug_enabled() - missing prototype' in your windows version? Rowley have already replied to my support ticket. Thats pretty good customer service, however, an error such as this in a commercial product raises questions in my mind...

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

Last Edited: Wed. Aug 31, 2011 - 06:09 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Some of the smaller PICs don't have any debug hardware. Microchip supplies header PCBs with special chips on them for debugging which cost about $25.

Leon Heller G1HSM

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

Quote:

Reference please.

Our company bought > 2 million mega8's - to develop we had to use ICE50's - these days we'd likely use mega88. AFAIK there is no equivalent of ICE50 for mega88. I guess you are saying that if mega88 didn't have dW then Atmel would jolly well have to make such a device?

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

gregsmithcts wrote:
Quote:
I quite agree with developing on a bigger chip and down-sizing for production.
Quite right. +1 vote :)

That's true, but as a hobbyist, for me that means I may have a mega328 in my stk500 when I start out coding, and end up with a mega88 (or whatever) on my board. I don't think I've ever needed an AVR with more than 28 pins, so having to use a higher pin count device just to get JTAG makes no sense to me. A small pin count device with dW suits me just fine...

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

Quote:
A small pin count device with dW suits me just fine...
Good point. Well made.

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

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

Cliff wrote:

> to develop we had to use ICE50's

Now, just don't tell our friend how much that one has been …

Brutte wrote:

> I just do not understand what can be made smarter than banging TCK.
> It is just shifting commands in and out..

Nope, as I wrote, it does a lot more than this. E.g., it handles all
the software breakpoints on behalf of the debugger, and that means
something like: fetch flash page, and keep it for a while, replace
intented breakpoint address by a BREAK instruction, then run. If
BREAK hit, reprogram original page. AFAIR, nothing comparable did
exist with OpenOCD for the classic ARMs, they just suffered from a
couple of hardware breakpoints the ARM engine provided.

No, I don't believe this piece of hardware actually has to be sold for
USD 300, and the AVR Dragon shows it could be had a lot cheaper. No,
I don't necessarily agree this strategy is the only way to go, and the
JTAGICEmkIII appears to be quite a bit cheaper, so well, it appears
even Atmel eventually changed their strategy.

And yes, I wish all this were documented, and we could just use
OpenOCD to attach GDB to an AVR. Yet, it's not the hobbyists who have
anything to decide in that game, and mind you, debugWIRE has for sure
*not* been implemented based on whether some hobbyists could find it
useful or not. All this is a million dollar business, and the only
reason for a semiconductor manufacturer to implement something this
way or another is that he thinks it will pay back some day, since
large customers (even if you bought a hundred, you wouldn't qualify
for that) are buying the stuff — paying back all the millions of
dollars, that had to be spent during development.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Jörg, if you still are around, or anyone else with the knowledge: I took a quick look in the CVS source repo for AVaRice, and there was one text file describing the mkII protocol, contributed by Colin O'Flynn. In it there is a note on it being of "only historical value" and a pointer to the AVR067 app note. I was not aware of this app note, and browsing it quickly it seems that this is a complete description of the PC-to-mkII-dongle protocol. If this is so then this would be all that was needed to create the mkII support in e.g. AVaRICE - no reverse engineering necessary.

Am I getting this correctly? (Just trying to get a better feel for the lay of the land).

Is there any similar official documentation on the Dragon protocol? (or does it use the mkII protocol? or was it reverse engineered?)

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:
I think he is suggesting that we go back to the days of special bond-out chips for development.

What are you talking about? Which sector do "we" represent, because obviously every market sector has its own specific requirements.

    A. Freaks <=1e2 B. Middle volume 1e2 to 1e5
    C. Mass production >=1e5

AFAIK Atmel does not supply such chips, although you can place AVR core in your product and I guess if they could place program memory in SRAM, they can also put it in ROM for you and provide appropriate tools.

Quote:
Some of the smaller PICs don't have any debug hardware.

Same as m8 and most of tiny tinys. I know some OTP PICs (-JW I guess) had a windowed package versions in ancient times of EPROM...

Quote:
If a manufacturer can fit an OCD block into a chip, why ever not?

It is advisable for "A" market, but not for "C" as OCD influences pricing. Besides mass market does not use universal uCs, but specialized ones (tailored).

Quote:
I guess you are saying that if mega88 didn't have dW then Atmel would jolly well have to make such a device?

To target "A", "B" or "C"?

For "A" such chip is useless with or without dW, as there are chips with JTAG and more pins at about the same price.

For "B" this dW is useless because nobody is going to play with dW Release chip without full blown OCD, counting free USARTs, ICPs, flash and SRAM bytes. You can develop your application on m1280 (or other JTAGed Mega) and just flush code into Release m88 later. Several #ifs and some wires do the job usually.

And for "C" not only dW OCD, but the whole chip is useless as you can order a cheaper, tailored one.

Quote:
That's true, but (..)having to use a higher pin count device just to get JTAG makes no sense to me.

Then we clearly disagree in here.
Because I do not understand why a hobbyist is using a chip with poor OCD (or without at all!) if one can use a "less poor" OCD.
I understand this is not a discussion about the pricing as m16 costs about the same as m88 for someone like me and you. I will also do not believe something with 32 IOs pins distracts your attention so you stick to something with 24 IOs. Do not worry, there are only 28 IOs left with JTAG enabled :)
The size also does not matter as I do not believe your hobby project hit package size limit, MLF44 did not fit your design but MLF32 did.

So what is the argument? DWC!

No RSTDISBL, no fun!

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

> ... and a pointer to the AVR067 app note. I was not aware of this
> app note, and browsing it quickly it seems that this is a complete
> description of the PC-to-mkII-dongle protocol. If this is so then
> this would be all that was needed to create the mkII support in
> e.g. AVaRICE - no reverse engineering necessary.

Unfortunately, it's no longer true that this documents *all* that is
needed, but yes, it documents most of what is currently implemented in
AVaRICE. Not implemented (since not documented) are in particular
certain things regarding Xmegas (namely the breakpoint handling), and
if you read Detlev Kraft's article in the mailinglist, you'll see that
AVR Studio 5 changed the protocol quite a bit beyond what is described
in AVR067.

Despite, "the devil lies in the details" (supposedly a Russian idiom),
and some of the details are described a bit vague in AVR067, so they
either had to be guessed, or reverse-engineered (or both).

Still, without that appnote, AVaRICE wouldn't be what it is.

> Is there any similar official documentation on the Dragon protocol?
> (or does it use the mkII protocol? or was it reverse engineered?)

The AVR Dragon basically uses the same protocol as the JTAGICEmkII,
only that it also implements the STK500v2 HVSP/PP commands the
JTAGICEmkII does not implement. But this is AVRDUDE's realm, not
AVaRICE's.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

> Besides mass market does not use universal uCs, but specialized ones (tailored).

That might have been the case in the old 8051 days. It's no longer the case.
There are *no* (zero, nada) AVRs which you could buy as OTP or mask ROM devices.
Still, they qualify to be "C" targets in your scale, as no serious vendor would
invest something that could only be sold as "A" or "B".

You might adjust your view of the world a little, welcome to the third millenium.

The only reason for *not* using a flash but a mask ROM device these days might
be some automotive/cosmic/aerospace areas where the elevated temperature makes
any EPROM technique too unreliable. But you'd have to pay for that, since the
manufacturer has to invest a lot more to get you a development device in
addition to the final production device.

(OTP only made some sense back in the EPROM days, since it allowed for shipping
the same chips in cheaper packages than those ceramic ones with the erase
window.)

Get rid of your opinion that AVRs were produced for hobbyists. They aren't.
No silicon vendor would care (much) for something that could only be sold to
hobbyists. Well, unless those hobbyists were millionaires.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Quote:
Nope, as I wrote, it does a lot more than this.

Misunderstanding. I know it and I understand it does, but I do not understand what for.
All these operations, readouts, register modifications and opcode substitutions can be made on the host side.
Anyway, JTAG is synchronous and not designed for Real-Time up/download so its timings do not influence the application (sent data is the same with JTAG clock==1Hz and 1MHz), the only thing that differs is the user's experience suffers if it is too slow. And with AVRs this cutting edge speed is of minor importance as these chips have small memories.

Quote:
"the devil lies in the details" (supposedly a Russian idiom)
I thought it is Polish! Anyway, same devils, same lies, only details are different.

There is also AVR060 Application Note which describes AS<->JTAGMK1 protocol (serial) and some internal JTAG things.

No RSTDISBL, no fun!

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

> All these operations, readouts, register modifications and opcode substitutions
> can be made on the host side.

Yes, they can, but some years ago, someone apparently thought it would make sense
to offload it from the host computer.

Remember, as Cliff already mentioned, in the past days of a millenium that is now
history, it was common to perform all the in-circuit development using expensive
emulation hardware (usually based on FPGAs then), costing several thousands of
bucks. Then, when the JTAG interface, designed for something completely different,
became customary, IC manufacturers started to realize one could also add OCD
hardware to that interface, making in-circuit emulation a lot less expensive than
it used to be. USD 300 for an emulator must have been a bargain then, and probably
nobody thought about the actual figure much: it had to be low enough to really be
a bargain still, but otherwise high enough to not look like a toy but a real tool. ;-)

I'm sure, nobody *ever* thought by that time, hobbyists would eventually want to jump onto
that emulation train at all …

> There is also AVR060 Application Note which describes AS<->JTAGMK1 protocol
> (serial) and some internal JTAG things.

Yes, sure. However, as I understand it, the roots of AVaRICE date back to a
time when all of that had to be reverse engineered. Once there was sufficient
progress, it had eventually been documented in AVR060.

But that's only my guess, it predates my days of joining the AVaRICE project.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

dl8dtl wrote:
And yes, I wish all this were documented, and we could just use OpenOCD to attach GDB to an AVR.

So googling around today (after reading this thread), there seem to be reverse engineered details out there on the dW serial protocol. Maybe enough to implement something useful, I don't know?

Question is, if this was picked up by an open source project - are Atmel likely to get protective over their protocol?

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

> Question is, if this was picked up by an open source project - are Atmel
> likely to get protective over their protocol?

Who knows?

My guess is, as long it helps selling their products, probably not. So
far, I know about just one case where they demanded from an opensource project
to stop using the "AVR" trademark: AVRUSB, now known as V-USB. Apparently,
the name AVRUSB sounded *too* generic, and somehow got into their way.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

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

Quote:
Question is, if this was picked up by an open source project - are Atmel likely to get protective over their protocol?

As I understand it, there is not much they can do to stop it "using law".

They can of-course do what they did with the event of AS5 (though this probably wasn't done for such reasons): Revamp the protocol, push new firmware onto the debugging devices and then keep it a secret (or at least require an NDA so they only let the big players onto the field).

The absolutely best outcome would of-course be that they opened up the protocol between the PC and the dongles. (As I understand it, "we" do not need to know the details of the protocols between the dongle and the AVR.) Or that they did pre-build drivers for the dongles for major PC platforms (Windows, GNU/Linux/Unix/BSD... and Mac OS).

In other threads here (or in private correspondence I've had in the past) someone argued that the absolutely best thing would be if they participated in something like the OpenOCD project.

@Jörg: I am very grateful for the insight you have provided re these matters. Off to join the mailing list now...

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:
The only reason for *not* using a flash but a mask ROM device these days might be some automotive/cosmic/aerospace areas where the elevated temperature makes

No, I am talking about mass market, the product which does not require reprogramming (like a microwave oven).

I do not want to have eager discussion about ROM vs FLASH as this is off-topic. Anyway, I cannot find a picture I had once - a Toshiba chip (I guess TMPN3120FE5M) 3x8-bitter, 16kB ROM and 3kB EEPROM on-board. The EEPROM occupied ~4 times the space of ROM on ASIC.

Quote:
Then, when the JTAG interface, designed for something completely different,

We are not discussing about ICE50 but JTAGMkx and AVROnce! These are from this millenium :) And USB (with 1MB/s transfer was introduced in 1995).

Quote:
the roots of AVaRICE date back to a time when all of that had to be reverse engineered.

Actually this application note and abandoning relatively simple JTAGMk1 support occured because of AVARice.

Quote:
there seem to be reverse engineered details out there on the dW serial protocol.

Where, what when? Reference please.
That would kill AVARice project together with most Atmel tools.

No RSTDISBL, no fun!

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

Jörg wrote:
if you read Detlev Kraft's article in the mailinglist, you'll see that
AVR Studio 5 changed the protocol quite a bit beyond what is described
in AVR067.

I'm not using XMega's at all (only Tiny's and Mega's), so this would mean that if I make sure that I use a Dragon with the firmware that comes with AS4 then I should be okay re firmware revision for current AVaRICE. Did I get this correct?

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]

Pages