RE: JTAGICE clones on ebay

Go To Last Post
34 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
david.prentice wrote:
I already own an ETT JTAGICE-1 clone.

Do you own some ATMegaxx4 or other "modern" Megas?
I am looking for someone willing to test those with avarice.
43pwm

No RSTDISBL, no fun!

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

Yes, I have got several "modern" AVRs. e.g. ATmega324PA.

Yes, I have tried Rowley with them. You can read fuses but that is it. i.e. you can't program Flash and you can't debug.

I would be very surprised if avrice would work. But I am happy to try it. (if you specify the exact software to install on Ubuntu)

David.

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

david.prentice wrote:
I would be very surprised if avrice would work.

I did try that with AT90USB128x and I could not see the difference in debugging this or any other "old" ATMega. I suspect there could be problems with beefier ATMega256x chips because of 17-bit PC.
Quote:
But I am happy to try it.

Ok, so I think that we should start from some test project.
Any m128 or m16 lying around? I do not own any "modern" Megas (except AT90USB128x) and I think we must start from something that 100% works here and there.

No RSTDISBL, no fun!

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

I have an AT90USB1287. I will try it with Rowley.

I have m128, m32, m16, m169. I know that these all work.

I am sure that I have tried m324, m644, m1284, m2560 and can confirm that they do NOT work.

David.

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

Then I suggest we should start from simple m16 + avarice + gdb.
If you want I can show you how to "install" Eclipse but that is just a (very cool) graphical interface. Not everyone likes it and IDE is not necessary to test debugging with JTAGICEMk1 so it is your choice.
I bet you already have some avr-gcc toolchain installed. Could you please tell me which versions you use?

I have

    avr-gcc 4.7.2 avr-ld 2.23.51
    avr-gdb 6.8
    avarice 2.9
The compiler and linker are not that important but it would be better to get similar elfs. The most important is the avarice - if you use a different version then I can change mine.

P.S. Can we officially call it hijacking now?
Perhaps we should move to a more appropriate location with that?
lai8p

No RSTDISBL, no fun!

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

I just tried AT90USB1287 with the JTAGICE-1 clone. You can only read/write fuses. You can't access flash or eeprom.

Yes, it is probably better to transfer to a new thread.
I can assure you that the JTAGICE-1 works fine with Rowley on Ubuntu. Although Rowley use ARM-GCC for their ARM IDE, they have their own C compiler and tools for the AVR.

I would imagine that avrice would work with JTAGICE-1. So I am not sure what you want to try.

I would prefer to just let a package-manager install an Eclipse etc. Either that, or you tell me which site to get your tools from.

Oh, I don't have much enthusiasm to do anything this evening. I would prefer to get the STM32F429 Demo compiling with Rowley first.

David.

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

Quote:
Yes, it is probably better to transfer to a new thread.

Ok, Mr. Moderator, can you do it please :)

Quote:
I would imagine that avrice would work with JTAGICE-1. So I am not sure what you want to try.

I want you to try debugging ATMega1284 with avarice.

Quote:
Either that, or you tell me which site to get your tools from.

Ok, I downloaded Winavr 20100110 from ? and after a year or two I downloaded avr-gcc 4.7.2 binary from ? I do not remember!
The compiler is not that important now, just get the avarice 2.9 and any gcc gdb or ld that works with avrs.

Quote:
I would prefer to get the STM32F429 Demo compiling with Rowley first.

That is understandable. Let me know when you are ready for avarice.

No RSTDISBL, no fun!

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

Before I attempt any download / installation, please can you confirm that you have avrice working with JTAGICE-1 clone and AT90USB1287.

Yes, I know that JTAGICE-1 works with a AT90CAN128.
The AT90USB1287 does not work with AS4 or Rowley.

David.

p.s. I am going to the pub.

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

Quote:
please can you confirm that you have avrice working with JTAGICE-1 clone and AT90USB1287.

Ok, I can post some print-screens later.
Quote:
Yes, I know that JTAGICE-1 works with a AT90CAN128.

I do not have AT90CAN128 but that one is "old" and officially supported.
Quote:
The AT90USB1287 does not work with AS4 or Rowley.

Ok, thanks, whatever the Rowley is :)

No RSTDISBL, no fun!

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

Here is a screenshot and the source code.
m2ew5

Attachment(s): 

No RSTDISBL, no fun!

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

Quote:
should move to a more appropriate location with that?
And what would you like the new location to be called?

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Ah-ha. I was very sceptical. After all, AS4, IAR, Rowley don't work with AT90USB1287 and JTAGICE-1.

So avrice must be writing some raw JTAG rather than use the published JTAG commands !

This has become very interesting. I will get off my backside and see if I can run Eclipse in Linux.

Mind you. If avrice really works with an $10 Chinese JTAGICE-1 then I would have thought all you Linux users would have mentioned it.

Oh. I think that Cliff has already split the thread. [indeed I did] This is that thread.

David.

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

Quote:
After all, AS4, IAR, Rowley don't work with AT90USB1287 and JTAGICE-1.

It is called marketing:

if(atmega != OLD){
 printf("Because of hardware limitations of this tool (...) 200$, thank you.");
}

Quote:
So avrice must be writing some raw JTAG rather than use the published JTAG commands !

AFAIK whole avarice project was started from hacking Mk1 protocol. After that Atmel decided to publish what had already been hacked in one of their ANs. So no, avarice couldn't have used published commands. About this specific subject you should ask The Hackers because I do not know these details.
Quote:
Mind you. If avrice really works with an $10 Chinese JTAGICE-1

That is how avarice project had started. It worked only with Mk1 and then all other stuff has been successively hacked. The most recent one was Mk3.
And I do not own "real" clone. I use m16-PU on a breadboard (but I guess this is irrelevant).
Quote:
then I would have thought all you Linux users would have mentioned it.

You Linux users who exactly?? I do not know Linux, I never used it. I am a windozer so do not count on my Linux support. Cliff is a Linux user but he is allergic to Eclipse.
eixsh

No RSTDISBL, no fun!

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

I gave up with Linux.

Since you say you are using Windoze, I tried that.
1. installed Eclipse Kesler C/C++
2. installed AVR Plugin dated 201203041437

It finds my WinAVR-2010 installation and can build and upload just fine via a JTAGICE-1.
However, I don't know what to do to start Debug.
I changed the default setting from "gdb" to "avr-gdb.exe" from the WinAVR path.

The Plug-In Help makes no mention of debugging. (and is dated 2008)

Quite honestly, it would be simpler to post you an ATmega1284 chip. You could try it for yourself. Please PM me with your address.

Since I already have a Dragon and a JTAGICE-mkII, I have not got much enthusiasm for Eclipse. Especially since it seems like LPCXpresso.

All the same, if you post links to the necessary components, I will give them a go.

David.

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

Quote:
installed Eclipse Kesler C/C++

I hope it is Kepler, not Kesler! And I also understand you didn't install a raw Eclipse IDE and that you already have CDT.

Quote:
installed AVR Plugin dated 201203041437

This old one should also work.
Quote:
The Plug-In Help makes no mention of debugging.

With Eclipse the plugins manage only the building and programming part, not debugging.
The gdb stuff is managed by "GDB hardware debugging" from Run->Debug Configurations*. That is made that way not only for AVRs but for all other architectures as well. This is because gdb debugging is all the same for avr, arm, mips, x86 etc so one components serves all. There is also a GUI Debug Configuration for dummies called "Zylin" Plug-In and I use that one as it has a more intuitive GUI (IMHO).

Mind that your AVR Plug-in version was released before dude 6.0 so it will not work with the most recent conf files. I use AVR Eclipse Plugin 2.4.1.20131008-1720-beta which works with any dude, including 6.0. Install that one (check the link above) and then you can use my whole Eclipse project.

One important remark: I will repeat what was already written in avarice manual because it seems Freaks just cannot skip that:
Because of high avrdude popularity, from some time Avarice project does not maintain "gdb load" command/functionality. It may work or may not on some targets - do not use it, do not touch it! They just do not want to put effort on the functionality that is already provided by AVRdude and there is no difference if you run "avrdude -U:flash:firmware.hex" or "gdb load firmware.hex" so they dropped the maintenance of that part.

Quote:
I have not got much enthusiasm for Eclipse. Especially since it seems like LPCXpresso.

Well LPCXpresso is based on Eclipse so it may be configured to look similar.

Quote:
Quite honestly, it would be simpler to post you an ATmega1284 chip.

I can buy an m1284 chip myself so thank you :) I do not use AVRs any more and I already have an ATMega128+32kB SRAM or AT90USB1287 so an ATMega1284 would be a downgrade. This was just meant to check the options that are available.

*IIRC this component, as many other components, is not installed by default. I use Eclipse for ARMs and MinGW so I already have some parts installed.

IMPORTANT EDIT:
There was a makefile bug discovered in CDT recently.
It causes some important dependency rules to fail. That is a nasty thing and can lead to inconsistent builds. If for example only some header file was edited then simple "make all" won't work.
As a workaround for now - it is enough to add

-MT"$(@)"

compiling option and that does the job.
cc43t

Attachment(s): 

No RSTDISBL, no fun!

Last Edited: Fri. Dec 20, 2013 - 10:51 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Silly question but why does Eclipse even need to enter this picture? Open two Command Prompts, run avarice in one, avrdude(program) then avr-gdb(debug) in the other and just get to the point where you can step a few instructions and explore RAM and SFRs.

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

Quote:
Silly question but why does Eclipse even need to enter this picture?

You are right, it does not. That is why
I wrote:
If you want I can show you how to "install" Eclipse (..) Not everyone likes it and IDE is not necessary to test debugging with JTAGICEMk1 so it is your choice.

I used avarice like that: "avarice -B 125kHz -j /dev/ttyS0 :4242 -R -P atmega16"
the -R is for reset but I never wired it. The :4242 is the port and you have to use the same in gdb, the -j is your com number (cygwinian) and -B is TCK rate (125kHz will do but you can use any up to 1MHz or F_CPU/4).
All gdb commands I used are visible in the console view in the print screen above. Most of them are only for convenience. I also tick breakpoint at main() so perhaps put "b main" before you run "continue" because you wont be able to notice when it enters main. Use hardware reset to restart.
Quote:
Open two Command Prompts, run avarice in one, avrdude(program)

I am not sure if you can dude AT90USB1287 via JTAGICEMk1 like that - I didn't test programming but debugging only. Perhaps either pretend m128 or use Flip or some other ISP programmer to program uC.
Quote:
and just get to the point where you can step a few instructions and explore RAM and SFRs.

I didn't run gdb in a text mode - I always use Eclipse IDE for debugging so I know it is theoretically possible to do it without MI but I didn't try that.
k6fyc

No RSTDISBL, no fun!

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

Following discussion is an answer to this request from A debugger on an AVR Xplained board? Really?

Johan wrote:
last time I had a look AVaRICE was required for OCD of AVRs on non-Windows systems.

Well, do you have any prejudices then? Indeed, avarice is a hacking project. I think it is one of the main causes of the over-engineered and custom Si EDBG + encryption chip on Xplained Pro. AFAIK the hackers succeeded cracking Dragon, JTAGICEMk1, Mk2 and Mk3 but failed with AvrONE so if you plan to use this ONE - forget it. I do not know if they plan to crack EDBG but unless the protocol is published I would not count on that (ask on avarice mailing list)..
Quote:
Is there support for AVRs intrinsic in GDB (as I understand it there never has been, isn't, and will never be.)

Anything specific? I have never seen Atmel Studio so please do not ask me "Does it offer same function as AS6.7.89 in Menu->Debug->third position from top".

AFAIK GDB provides much more than ASes but as you are the only YES freak and remaining shy YES freaks had deserted there are not many opportunities to discuss about it :)
After reading the gdb posts in here one can get the impression that freaks state GDB is bad, Eclipse is slow and Avarice is evil but when you ask them about anything specific then it occurs they didn't RTFM or they didn't use any debugger in their lives at all.

EDIT:

I wrote:
You Linux users who exactly??

Mind I do not know linux.
bwgdj

No RSTDISBL, no fun!

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

Yes, I have tinkered to and fro with AVaRICE and GDB on top of that. I can nor recall if I got any IDE working on top of that.

The point with having an official Atmel debug driver for GNU/Linux, or an official specs of the protocol, is that it will not be toppled when a new debug dongle comes along. Your own statement above about the "AVR One!" serves as an example. That thing is really expensive, so not many people will own one.

But how about the brand new "Atmel ICE"? It comes with perhaps the most competitive price tag of all debug dongles from Atmel.

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

For me the "barrier" to using avarice and avr-gdb is simply the lack of a decent simulator. simulavr (the later one) tries but it clearly doesn't get the support for 300+ AVR models that the simulator in Atmel Studio does. That's why I'd use Windows and AS4/6 in preference to anything else.

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

Quote:
The point with having an official Atmel debug driver for GNU/Linux

I cannot help you with Atmel ICE driver hacking. Ask "The Hackers". Or Atmel.

Frankly I do not understand why would anyone want to use proprietary Atmel ICE under !ASes (be it Eclipse or CodeBlocks or other stuff).

My point is that if you use a regular AVR8s (I am not talking about crippled dW, brain-dead tn4 or OCD-less m8 versions) then you can use mentioned alternatives.

And if you want to use ARMs (be it Cortex or TDMI from Atmel, STM, Freescale or Nuvoton) then you can use any supported dongle you can imagine, not necessarily Atmel's proprietary one with encription chip, ASes tied and surprises.

So IMHO potential customer for Atmel ICE must love all three: MSVS+AVR8s+SAMs.
If the lust involves only two out of three temptations - EDBG won't fit.

Now, as you try to suggest, if Atmel had provided gdb $32/$85 EDBG protocol (be it involving The Hackers or their own team) then that would have killed Dragon, Mk2, Mk3 in one fast go. As ONE has already been successfully killed last year that would have proved Atmel's consequence in their (unprecedented) marketing-fu.

No RSTDISBL, no fun!

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

Quote:
I cannot help you with Atmel ICE driver hacking. Ask [...] Atmel.

Well, that is exactly what I did in the other thread.

Quote:
Frankly I do not understand why would anyone want to use proprietary Atmel ICE under !ASes

In general, because I am afraid of new AVR models not being supported, or taking a long time to get supported, by a clone. For a debugger dongle from Atmel itself I would expect that any required firmware updates would come out relatively quickly.

Quote:

if you use a regular AVR8s (I am not talking about crippled dW [...])

Which is one of my points. Atmels supports dW devices in their debugging dongles. I use the ATmegaX8 family frequently.

Quote:
Now, as you try to suggest, if Atmel had provided gdb $32/$85 EDBG protocol (be it involving The Hackers or their own team) then that would have killed Dragon, Mk2, Mk3 in one fast go.

I'm not so sure. The programming protool is open, and AFAIK this has not killed e.g. the AVRISP mkII. If Atmel feared this killing, they could just supply a pre-built binary that spoke to their dongles downwards and to GDB upwards all would be fine.

Anyway, although they have released a GNU/Linux tool chain they have not released any debugging driver binary. One reason could be that they simply think there is no interest in this from "the community". If so the chances of this ever happening is slim, to say the least.

I have both a Dragon and a JTAGICE3 handy so next week-end there might be some time allocated for some experiments with AVaRICE again.

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 wrote:
In general, because I am afraid of new AVR models not being supported, or taking a long time to get supported, by a clone

My remark didn't really apply to commercial usage but to hobbyists like me who really do not care if uC runs at 16MHz or 20MHz as long as it is $3, has 128kB of flash, decent peripherals and at least 50IOs. I do not/didn't require cutting edge 8-bit technology and I buy/bought tens, not thousands of uCs/year.

If you use AVR8s commercially and banging with reduced IO count dW saves you money - go for the most advanced tools (although I would still recommend development on something bigger, like ATMega1284).

Johan wrote:
Atmels supports dW devices in their debugging dongles. I use the ATmegaX8 family frequently.

I also like ATMegaXX8, my favorite is ATMega128 :)

Johan wrote:
I'm not so sure. The programming protool is open, and AFAIK this has not killed e.g. the AVRISP mkII.

I am afraid this is misunderstanding.
I wrote that Atmel won't be able to sell any Mk2, Mk3, Dragons and alike if EDBG offers same functionality for sixths part of the previous tool's price. Now imagine the hypothetical situation when they introduce an AVRISP mkMMXII for 200$ and two months later there appears a device that does same programming but now costs $32.
Does "I'm not so sure" apply now?
Conclusion: gdb protocol is the last advantage of mentioned tools now*.

Johan wrote:
they have not released any debugging driver binary.

Even if they did - AVR8s are waste of time now. It is the beginning of XXI-st century, ARM era!

Cliff wrote:
the lack of a decent simulator

*BTW, I have heard Atmel included avr-gdb in AS6.2 instead of their own home-brew one! Is that true? If so, Cliff, I am afraid AS6.3 is going to relay on Simulavr and AS6.4 is going to be Eclipse-based :twisted: So sorry.

No RSTDISBL, no fun!

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

Quote:

Is that true?

Seems so:

C:\Documents and Settings\asl\My Documents\Atmel Studio\test\test\Debug>cd "\Program Files\Atmel"

C:\Program Files\Atmel>dir
 Volume in drive C has no label.
 Volume Serial Number is E0DD-96FE

 Directory of C:\Program Files\Atmel

28/02/2014  16:50              .
28/02/2014  16:50              ..
28/02/2014  17:12              Atmel Software Framework
25/02/2013  17:59              Atmel Studio 6.0
29/04/2013  12:15              Atmel Studio 6.1
28/02/2014  17:16              Atmel Studio 6.2
28/02/2014  17:08              Atmel Studio Extensions
28/02/2014  17:08              Atmel Toolchain
05/03/2013  16:52              Atmel USB
09/05/2012  16:20              AVR Studio 5.1
16/12/2011  16:48              AVR Tools
               0 File(s)              0 bytes
              11 Dir(s)  14,563,880,960 bytes free

C:\Program Files\Atmel>find . -name avr-gdb.exe
./Atmel Toolchain/AVR8 GCC/Native/3.4.1051/avr8-gnu-toolchain/bin/avr-gdb.exe

C:\Program Files\Atmel>

also:

C:\Documents and Settings\asl\My Documents>avr-gdb -v
GNU gdb (AVR_8_bit_GNU_Toolchain_3.4.4_1162) 7.6.2
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i686-pc-mingw32 --target=avr".
For bug reporting instructions, please see:
.

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

Cliff wrote:
Seems so:

Atmel could not lock this GDB or use some dirty AS tricks because GDB is
Quote:
License GPLv3+: GNU GPL version 3 or later

so does this mean that AS6.2 supports avarice + JTAGICEMk1?
Can you try that please? No need to start ASes, just connect that gdb to avarice and do some IO wiggling. Here is an Mk1 recipe if you do not already have a bunch of these.

Please don't tell me AS6.2 runs on avarice now. They must have used some kind of middleware, did they write their own atmelice from the ground then (pun intended)?
pvauw

No RSTDISBL, no fun!

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

Quote:

Can you try that please?

I don't have a JTAGICE mkI

In the release thread for 6.2 someone from Atmel (danv?) said that it was only for ARM that they are using arm-gdb as the backend at present but the fact they are now bundling a copy of avr-gdb when I don't think it was there before makes me wonder if the plan is to shift AS6 to avr-gdb too. If I just start AVR simulation in AS6.2 procexp shows that it has spawned atbackend.exe just as it always did.

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

Quote:

In the release thread for 6.2 someone from Atmel (danv?) said that it was only for ARM

Currently. We are having issues with avr8 crashing on us. If you start a debug session on arm, you can see that we start up arm-gdb-none-eabi.exe by default now. We will still keep the choice open (under project properties|advanced) as we have also seen that some elf specific elf files crashes gdb but works in our internal debugger. The reason for the shift is basically to get a debug experience that utilizes all the magic that gcc sprinkles around :)

To keep confusion minimal, we use gdb as a run controller, e.g. to issue step to, run to and similar commands, and to evaluate expressions. This is done in a translation layer in atbackend.exe. The gdb instance then talks to another layer in atbackend.exe, doing to low level control of the target and debugger. There is no avraice involved or change in the API between Atmel Studio and atbackend.

:: Morten

 

(yes, I work for Atmel, yes, I do this in my spare time, now stop sending PMs)

 

The postings on this site are my own and do not represent Microchip’s positions, strategies, or opinions.

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

Brutte wrote:

so does this mean that AS6.2 supports avarice + JTAGICEMk1?
Can you try that please? No need to start ASes, just connect that gdb to avarice and do some IO wiggling. Here is an Mk1 recipe if you do not already have a bunch of these.

Good Gawd. Not only thread Necromancy, but project Necromancy too. I found the folder on my drive recently that had the Butterfly MKI clone code in it. Talk about rising from the dead...

I think I am on My 5th dragon now. There is the Dragon that works on my old win98 machine, which runs I think studio 4.17. I think this is the only machine that has a true serial port for the ICE200. (anyone want an ICE 200 I have two.)

My first dragon, sometimes does not work. I damaged the level shifters somehow. I think the parallel programmer works still.

The replacement dragon gets the most use, but It only works with studio 4.19 under XP

I keep a dragon for studio 4.19 on a clients machine. (The MKII lives at the other client, still with 4.19 firmware Also on XP)

The 5th dragon is for Studio 6, which I rarely use except to experiment with, Which has not been done in recent memory. If I ever do have to visit the dark side of studio 6 (Probably for ARM development) I will need to get the newest dongle. Now if only such dongle would work on a mac under GDB and eclipse ...

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

jporter wrote:
I found the folder on my drive recently that had the Butterfly MKI clone code in it.

I have reviewed your project: Mk1 running on ATMega169..(project linked there). I do not own m169 but from the description it looks like it should JTAG same AVR8s as original Mk1 (that is all AVR8s up to 128kB).

jporter wrote:
The 5th dragon..

Hell lot of dragons out there.
I have never heard anyone keeping 5 (~live) dragons. Do these have names or do you call them by sequential number :lol:
jppdy

No RSTDISBL, no fun!

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

Quote:

I have never heard anyone keeping 5 (~live) dragons.

For reasons quite different from Janes, I actually do too. It might even be six.. I have the Dragon I got from Atmel when they first came out. I might have bought a v2 (mounting holes and all) when that surfaced - not sure (and even with a lot of gear archaeology there is only a 50% chance I will be sure..). I defititively got four dragons for an educational event that I ran a few years back.

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

Brutte wrote:
jporter wrote:
I found the folder on my drive recently that had the Butterfly MKI clone code in it.

I have reviewed your project: Mk1 running on ATMega169..(project linked there). I do not own m169 but from the description it looks like it should JTAG same AVR8s as original Mk1 (that is all AVR8s up to 128kB).

It was a straight up port from the m163 to m169. I basically did a search and replace on the SRAM pointers to move the starting SRAM address. I treated the TAP controller as a black box.

I think the code is still programmed in one of my butterfly's I do not really have anything to test it on since I tend to work with Mega328 and Tiny85s so mostly use debugwire.

I had a project that used the AT90S8515 which has the same footprint as an i8051. This took advantage of external SRAM. For some reason the JTAG pins on the m162 which has the same footprint are on the upper address lines. This rendered JTAG debugging of the external memory useless. When I moved the project from floppy disk to CF card then to SD memory I no longer needed the 128K of Sram to buffer the whole track of the disk.

Quote:

jporter wrote:
The 5th dragon..

Hell lot of dragons out there.
I have never heard anyone keeping 5 (~live) dragons. Do these have names or do you call them by sequential number :lol:
jppdy

None of them have names. They are known by location and which laptop they connect to.

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

> AFAIK the hackers succeeded cracking Dragon, JTAGICEMk1, Mk2 and Mk3
> but failed with AvrONE so if you plan to use this ONE - forget it.
> I do not know if they plan to crack EDBG but unless the protocol
> is published I would not count on that (ask on avarice mailing list)..

The old Mk1 days predate my involvement into AVaRICE. Yes, it
probably started out by reverse-engineering the protocol (and I
remember someone even started to reverse-engineer the raw JTAG stuff
to some degree). Then, Atmel somehow decided (maybe triggered by some
kind of behind-the-scenes talks of Ted Roth?) to publish the
protocol. AVaRICE could then be completed based on that.

I then added the MkII protocol to AVRDUDE and AVaRICE. Without
digging up emails from about a decade ago, I cannot tell you for sure
whether I've already got a public protocol spec when I've been
starting. Perhaps I got an advance internal copy already before it
got published, but I rest you assured that nothing had to be
reverse-engineered for that effort, and the protocol spec was later
published as AVR067.

Alas, the publication of AVR067 should be the last one for a long
time. In particular the addition of Xmegas to the protocol would have
required updating that document but that never happened (at least for
the debugging side of the coin — the programming description
eventually got added to a newer revision). This eventually led to a
situation where users wanted it badly enough to reverse-engineer that
part, so it could be added to AVaRICE.

With the advent of the JTAGICE3, again, no public protocol description
was available, so users started to reverse-engineer the protocol.

Finally, with EDBG, now there's an officially published protocol
description again and, as years ago, me as well as other AVRDUDE
volunteers got advance copies from Atmel in order to be able to extend
AVRDUDE for it. Since EDBG is basically a CMSIS-DAP wrapper around
the existing JTAGICE3 protocol (as it turned out), it's ironic that
we've now got an official documentation for what we already
reverse-engineered before. :) So we are in a situation where AVRDUDE
can handle a JTAGICE3 irrespective of its firmware version (which
Atmel Studio cannot :).

I haven't come around yet to add the EDBG wrapper also to AVaRICE, but
it will happen, too. That will cover the 3.x firmware versions of the
JTAGICE3, as well as the onboard EDBG of XplainedPro boards plus the
new Atmel-ICE debugging tool. (I cannot say whether the mEDBG is fully
compatible with it, too. If so, it can be supported as well.)

As for the AvrONE!, it simply never happened that someone even asked
about supporting it, let alone started to reverse-engineer the protocol.
I'm sure, if someone would have needed it bad enough it would have been
possible to add it, but given the price tag, it was probably always out
of the question for most if not all of those people using AVRDUDE and/or
AVaRICE.

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:
As for the AvrONE!, it simply never happened that someone even asked
about supporting it, let alone started to reverse-engineer the protocol.

Jörg, Dean and AvrONCE

No RSTDISBL, no fun!

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

I would prefer another IDE than Atmel Studio (6.2) because AS cannot manage a solution satisfactorily. For example, I created a solution with about twenty projects, containing drivers, unit tests, and product firmware for different targets. Every time I create a new project, for example for a GPS driver, I have to re-create the entire ASF stack which will then be a copy and not a link to an existing ASF stack. Anything I modify in the ASF stack I have to repeat over many of the other projects. I could create a common ASF stack for some of the projects but not all, because not all projects use the same ASF drivers and services. In Eclipse, I can just create configurations that exclude selected parts of the ASF stack. (In NetBeans it is more tedious because this selection has to be made module by module and not by folder.)

 

Some of years ago I moved a similar solution, in that case one that needed an HID stack for one configuration and an HID-CDC stack for another configuration to Eclipse CDT. I also got the debugger working under Eclipse using avarice with MKII. (In AS a configuration in Eclipse or NetBeans would have to be a project because modules cannot be excluded based on configuration.) Unfortunately, I had to go back to Atmel Studio a couple of years later because I got a JTAGICE3 which avarice did not support at that time. Under Atmel Studio, I had to create two projects, tediously creating a common folder tree and linking all the common application modules, and two separate folder trees for the HID and HID-CDC stacks.

 

To summarize, as soon as I get avarice with JTAGICE3 support working I shall switch back from AS to Eclipse or NetBeans. We are in the process of selecting an MCU for our new product. This selection will also depend on the weak project management that AS provides.

Last Edited: Wed. Sep 30, 2015 - 04:29 PM