AVR Dragon was cracked! No 32k code size limitation~~

Go To Last Post
118 posts / 0 new

Pages

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

Thanks,Cliff!

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

Cliff,
That was a good idea. As I noted in an earlier post this thread has become more volitile than the nuke energy thread.

I think best for me to just keep quiet and save my pennies for the JTAGMKII

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

Soooo, has anyone actually tested this? Is it possible to debug bigger devices than 32kb?

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

Hmm. Maybe this 'fix' could fix my baked dragon too? Naah, i think i stick to my ice2 in stead. Hmmm,,, Maybe they could fix my Ice2 into an AVR ONE? THAT would be interesting! :mrgreen:

Regards
Vidar (Z)

----------------------------------------------------------

"The fool wonders, the wise man asks"

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

It sounds like the 'hack' was in a windows driver. Does that mean that there never was a 32kb limit using avrice under Linux?

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

Another thought:

Atmel is profiting a lot from the work of the open source community. There is a lot of free firmware for the ATMEL mikrocontrollers. A lot of support is done for free. Due to this the mikrocontrollers are very well known by studends which tend to use this mikrocontrollers later with their professional work.
There are a lot of competing mikrocontroller manufacturers to Atmel. The user community helps ATMEL to gain market shares.

Therefore I would not condemn it, if there is a software hack extending a little bit the limits of the dragon.

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

I would like to suggest a morality forum section. That way we could have that place to get our daily whipping for having bad ideas, actions, thoughts and other bads.
Keep the AVR forum for technical issues only.
Once in awhile I could post to the morality forum and then receive my just dues. :twisted:

I'll believe corporations
are people when Texas executes one.

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

> Does that mean that there never was a 32kb limit using avrice under Linux?

As I read it, the hack is twofold: it modifies a DLL, presumably so
AVR Studio is actually willing to offer the Dragon for debugging the
larger controllers in the first place. You're right, this was never
an issue with AVaRICE at all, it never bothered to check this.

The second part is modifying the XML files so they pretend a smaller
ROM size than the devices actually have. Without that, the Dragon
will simply bail out on a larger device the first time it is asked for
any command that is typical for debugging sessions. The AVaRICE
counterpart for that would be to hack src/devdescr.cc. However, if
you can find a device similar to your debugging target but with a
smaller ROM size (e.g. an ATmega324P when you want to debug an
ATmega644P), it's always possible to override the JTAG ID based CPU
decision from the command-line.

I always wondered what the Dragon firmware would do if the device then
started to step into higher ROM addresses... Apparently, it doesn't
care (it probably could not do much against it anyway).

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:
> Does that mean that there never was a 32kb limit using avrice under Linux?

As I read it, the hack is twofold: it modifies a DLL, presumably so
AVR Studio is actually willing to offer the Dragon for debugging the
larger controllers in the first place. You're right, this was never
an issue with AVaRICE at all, it never bothered to check this.

The second part is modifying the XML files so they pretend a smaller
ROM size than the devices actually have. Without that, the Dragon
will simply bail out on a larger device the first time it is asked for
any command that is typical for debugging sessions. The AVaRICE
counterpart for that would be to hack src/devdescr.cc. However, if
you can find a device similar to your debugging target but with a
smaller ROM size (e.g. an ATmega324P when you want to debug an
ATmega644P), it's always possible to override the JTAG ID based CPU
decision from the command-line.

I always wondered what the Dragon firmware would do if the device then
started to step into higher ROM addresses... Apparently, it doesn't
care (it probably could not do much against it anyway).

Sir,

The modification is just used to change the limite from 32K to 256K. The author said it is so simple.

The author also modified the XML files to hack the limite earlier and support some devices, but finally he decided to hack the DLL divers to solve the problem throughly.

The RAR file contains two parts:
1: Hacked DLL.
2: Original XML files
We just need the DLL only. The original files of AVR Studio is just for recover the files because the author released the modified XML file solution earlier, someone repalce the XML files but now the new DLL solution needs the original files.

The author said:

'The AvrTargetDragon.dll will creat a availaible devices list in the RAM after the fist call, then all the devices info will be red here.
During the list creating process, AvrTargetDragon.dll will read the avrdragonparts.cac(this is the XMl file), if the
%d was less than 32K, this devices will be added in the list, or ignored. So, I just try to find the comparetion process, the problem was solved.'

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

For me it's easy!

I'm loyal so: I want to support ATMEL as they support the world with free tools and support. In fact it the most inexpensive way for my kids to play I've found so far. I want them to be profitable, successful, and out compete the competition. So I’ll only buy their products.

I will hack the code and test it (just to learn) but I will buy only ATMEL tools for actual production work even if for my hobby. I’ll spend the same time others use looking to save a buck on ways I can earn a new buck to pay for it.

My ethics and (spiritual not community) morals won’t allow otherwise so will never have to even wrestle with the problem.

I won’t judge others either we all have free choice to be who we wish to become in life by our choices.

Resistance is futile…… You will be compiled!

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

> The modification is just used to change the limite from
> 32K to 256K. The author said it is so simple.

That doesn't match my very own observation made with AVaRICE.
Whenever trying to debug a device with more than 32 KiB of ROM
(as reported to the Dragon in the device descriptor), the Dragon
eventually responded to one of the debugging commands with a
simple "RSP_FAILED" response. I forgot which command the response
was actually sent to, but it appeared to be deliberately chosen
so normal programming commands would work but debugging doesn't.

Of course, that's been about a couple of years ago, when the Dragon
was still new. There's a chance more recent firmware versions behave
differently. If it's true what you're writing, then the answer to
the question about AVaRICE and Linux would be: yes, it must always
have been possible to use it that way, even for devices with > 32 KiB
of flash ROM.

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

All this now is a history :) Actually reading this stuff(war) year or so latter is a kind of funny :)

Right now ATMEL decided to take another way for Dragon, by adding, in 4.18 RC2/beta, support for all AVR devices, including XMega :) It seems the 32kb era for Dragon is over :) For example, ATmega128 has support for JTAG debugging :)

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

This actually seems to be true. I initially thought that there was some confusion between programming support and debugging support, but in the release notes

Atmel wrote:
AVR Dragon support for all AVR 8-bit devices including XMEGA. Programming and debugging within AVR Studio and command line software support for ELF production file format.

Gotta get home to my Dragon and check out if I can JTAG my old ATmega128!

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

They don't mention the level of support.

Anyway, two of my three Dragons were broken and are hopefully already recycled into something more useful. Like becoming part of a park bench. And I can't find the third on. So I think I'll skip this opportunity to break the third Dragon.

Stealing Proteus doesn't make you an engineer.

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

so now Dragon supports all jtag devices? really?

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

JohanEkdahl wrote:
Gotta get home to my Dragon and check out if I can JTAG my old ATmega128!

So can it JTAG?

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

AndersAnd wrote:
So can it JTAG?
Yes. I did a small test yesterday with a m128. It seemed to work.

Pages