Arduino IDE sending avrdude commands to avrisp2 too fast

[virtual812]

Hi, have come across an issue when burning a bootloader with the IDE.

The IDE sends the 2 avrdude commands too quickly without the AVRispMK2 getting a chance to reset.

I tested this with a batch file by copy/pasting the avrdude commands from the verbose output of the Arduino IDE window.

I was able to reproduce the issue by sending the commands 1 after another immediately using a batch file.
I tried the same again with 'wait 1' to add a 1 second delay to the batch file between commands and the issue was resolved.

This issue may depend on speed of computer.
It would be good to experiment with delays as a full 1 second delay may not be required.

If anyone has any idea how i might add and accurate sub 1s delay to a batch file I'd be happy to test and report my findings.

PC is an i5 3570K, 8gig, Win7x64, Intel SSD

Cheers.

[jogo-]

For a 1s delay within a Win7 batch file, you can try this solution: http:https://ss64.com/nt/timeout.html

Syntax
      TIMEOUT delay [/nobreak]
Key
   delay  Delay in seconds (between -1 and 100000) to wait before continuing.
          The value -1 causes the computer to wait indefinitely for a keystroke 
          (like the PAUSE command)

   /nobreak
          Ignore user key strokes. (Windows 7 or greater)

[virtual812]

Hi jogo,

My wording in the original post is a bit wierd now that i look back at it, but i do have a 1s delay working.

The goal is for a sub 1s delay (eg: 500milliseconds ?) to see how short a delay causes the problem to re - occur.

My hope is that i'm not the only one suffering this issue, and that the people whom work on that part of the IDE can insert a very short delay between sending multiple commands.

I'm actually curious about it and would be interested in seeing where in the code that the "Burn Bootloader" code exists.
I might not make much sense of it , but after getting started with Arduino it has made me appreciate code elsewhere.

[darkwingz24]

I upgraded to Arduino 1.6.x and cannot burn the bootloader anymore with AVRISP mkIII. I could under previous versions of Arduino. I don't know if this is why but you are not alone and this has happened on all computers we upgraded arduino to 1.6.x. We still have an older copy of arduino and we have to use that to burn the boot loader. Would definitely like to see this fixed.

[virtual812]

darkwingz24,

If you turn on verbose output in the IDE settings and check the error output you may find 2 commands are run.

You can paste these commands into a command line and run them, one after the other.
If it works this way leaving a short moment before pasting and executing the second command it is indeed the exact same issue.

If i knew a bit more about programming i'd have a go at making the change myself, i'd bet it would be trivial to add a 1s delay between commands.

[ghost]

Last time I tried burning Bootloader I found out that the avrdude-version comming with 1.6.3 was compiled without USB support.

[ffissore]

@adadnc this has been fixed and released. use boards manager to upgrade your avr core to the latest

[darkwingz24]

@virtual812 I turned on verbose mode as you said and copied the two instructions:

"C:\Program Files (x86)\Arduino/hardware/tools/avr/bin/avrdude" -C"C:\Program Files (x86)\Arduino/hardware/tools/avr/etc/avrdude.conf" -v -patmega328p -cstk500v2 -Pusb -e -Ulock:w:0x3F:m -Uefuse:w:0x05:m -Uhfuse:w:0xDA:m -Ulfuse:w:0xFF:m

"C:\Program Files (x86)\Arduino/hardware/tools/avr/bin/avrdude" -C"C:\Program Files (x86)\Arduino/hardware/tools/avr/etc/avrdude.conf" -v -patmega328p -cstk500v2 -Pusb -Uflash:w:"C:\Program Files (x86)\Arduino\hardware\arduino\avr/bootloaders/atmega/ATmegaBOOT_168_atmega328.hex":i -Ulock:w:0x0F:m

I ran these as separate commands in a command prompt and boom, it works! I have also noticed that if I click "burn boot loader" in Arduino IDE enough times it does work about 1 in 20 times. So definitely a timing issue where the second command is issued too soon. At least I can make a batch file for this as I have 350 boards to program and this would not have been good to do with a 19/20 failure rate. Thank you for the help and guidance.

[bperrybap]

ffissore,
How was this fixed?
I reported and described this issue in detail in issue #650 from the old google.code repo back in 2011 and again in this thread: http:https://forum.arduino.cc/index.php?topic=316061

The imported bug from the google code repo is here:
https://github.com/arduino/Arduino/issues/650

It is a bug in avrdude and should not be fixed by adding delays into the IDE.
See the links above for more details and additional links to the bug reports.

[millerlp]

Confirming that this continues to be a problem with Arduino 1.6.4 (downloaded 2015-05-22) and an AVRISP mkII on Windows 7 x64 when trying to burn the ATmegaBOOT_168_atmega328_pro_8MHz.hex bootloader to a new chip. The short delay between the two separate avrdude commands issued by the IDE (first burning the fuses, 2nd burning the bootloader) appears to cause avrdude to lose the usb connection to the AVRISP when the 2nd avrdude command is issued. This results in an error message following the 2nd avrdude call:

D:\Arduino\arduino-1.6.4\hardware\tools\avr/bin/avrdude -CD:\Arduino\arduino-1.6.4\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -cstk500v2 -Pusb -Uflash:w:D:\Arduino\arduino-1.6.4\hardware\arduino\avr/bootloaders/atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex:i -Ulock:w:0x0F:m 

avrdude: Version 6.0.1, compiled on Apr 15 2015 at 19:59:58
         Copyright (c) 2000-2005 Brian Dean, http:https://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "D:\Arduino\arduino-1.6.4\hardware\tools\avr/etc/avrdude.conf"

         Using Port                    : usb
         Using Programmer              : stk500v2
Error while burning bootloader.
avrdude: usbdev_open(): did not find any USB device "usb"

Issuing the two avrdude commands manually (i.e. slowly, by hand) via the Windows command terminal works successfully and results in a functional chip with a bootloader, so the issue certainly appears to be the speed at which the Arduino IDE is issuing the two avrdude commands to the AVRISP mkII.

[bperrybap]

No! Once again. The real issue is NOT in the IDE.
Nor is the IDE inducing this issue by not waiting long enough between avrdude commands.
The issue in avrdude.
If you read information in the links that I provided, I detailed in great detail what the problem is.
I'll summarize here again for those that won't go read the information in the links I provided.

avrdude is intentionally resetting the USB just before it exits. It does this every single time.
It is doing this because of an issue in libusb. But regardless , it is avrdude that is resetting the USB which is what is causing this issue.
Resetting the USB means that every single device on the USB must re-enumerate after avrdude exits. Until a device finishes re-enumerating, it essentially does not exist to any application that tries to look for it. The atmel devices like the MKII and the Dragon take a while (second or two) to complete their re-enumeration with the OS as they seem to internally reset themselves when the USB is reset.
avrdude does not attempt to look very long for devices on the USB when it starts up. When avrdude starts up, it does one quick look for the USB device specified and when it doesn't see the device, it bails out. The problem is that if your run avrdude immediately after just running avrdude, the device you are using may not have completed it's USB re-enumeration since avrdude just kicked it off the USB by resetting the USB when the previous avrdude command finished.
This is a avrdude bug and needs to be fixed in avrdude.
It is avrdude that chose to work around a libusb bug by resetting the USB. The problem is that avrdude is not then doing what is necessary to properly recover from its libusb work around the next time avrdude starts up.

There are ways to work around it without modifying avrdude:

• add delays in the IDE between back to back command.
  This is a dumb way to handle it as it adds a blind delay even when it is not needed. Furthermore, this is what was already being doe and the problem is how long is long enough? The amount of time is dependent on the OS and the speed of the processor and the speed of the USB device.
• Change the IDE to use a single avrdude command vs two.
  This is a preferred work around since it avoids the back to back avrdude command issue since it does everything in a single command. This is the solution that optiboot switched to for its makefiles and build scripts.
  I recommend doing this even if avrdude is fixed as there is no reason to do two back to back avrdude commands when it can all be done in a single command.
  This will also slightly speed up the operation.

The real solution is to actually fix it in avrdude:
The fix is just a couple of lines of code. If you read the links I posted above you can see the actual fix. All it does is provide a loop that if the specified USB programming device is not found on the USB, it waits a few milliseconds and looks again. This process repeats for several seconds. This gives added time for a device to re-enumerate, if it needs it.
It avoids having to do a dumb blind wait between avrdude commands, like is currently being done in the IDE. And the problem with a blind wait is that you don't want to wait too long as it slows down the operation but then if you don't wait long enough it doesn't work, which is what is happening the IDE.

The real answer is to fix the IDE to do everything in a single command which avoids the problem.
Then also fix avrdude so that back to back avrdude commands work again, but getting Joerg to fix avrdude is really tough.
I've not been able to move this forward in over 4 years.

--- bill

[millerlp]

Thanks for the clarification Bill. I did originally read all of your info in the other links on the google code site. As you've repeated several times here and over there, one solution to this bug that has broken the function of the Arduino IDE is to alter the way the Arduino IDE is handling the bootloader burn process. It appears that you agree that a workaround could be made to the Arduino IDE to restore full functionality that existed in prior versions of the Arduino software. Seems like a valid topic for the Arduino bug tracker, and separately for the non-responsive avrdude author?

[bperrybap]

This isn't something that just broke. This issue has existed for MANY years and still exists today.
So it isn't something that used to work that now doesn't.
I have IDEs all the way back to 0015 and they all have this issue; most users don't see because they are not using the affected devices.
Ironically, it only affects the official atmel ISP programmers, not any of the 3rd party programmers like the bootloaders, TinyUSB, or USBasp.

And yes it is a good topic for the Arduino bug tracker and for avrdude and that is why I entered it in the Arduino bug list and on savannah tracker over 4 years ago and it is still there today (It was imported into the github issues when arduino was transitioned from Google Code to github)
And there were other reports of this issue in savannah several years before I fully reported the issue on savannah.

I have fully documented the issue, I have provided a fix for avrdude and and also provided a work around for the IDE.

Since I don't have update access to either repository I can't update the code to either fix it in avrdude or add the work around to the IDE.

While the ideal solution would be to fix ardude, after more than 5 years, it seems pretty clear that this may not ever get fixed in the main line avrdude code.
So barring the Arduino team taking on delivering a patched avrdude, I'd suggest that the IDE work around the issue by doing a bootloader burn operation with a single avrdude command vs 2. The IDE can do the exact same thing it does today, including the fuse operations in a single command, so there is no reason to do it in two.

--- bill

[virtual812]

This is insane.

I have followed the links over to avrdude and can now see where the true
problem lies.
It seems that blame and bullshit is being spread around rather than
solutions.
I can why you're frustrated Bill.

Ultimately here I am, an idiot that can hardly make a light blink, having
to stuff are about trying to get to the bottom of why I can't burn a boot
loader!

I'm genuinely surprised I figured it out.

A message to anyone reading this with the power to do something about it,
please fix it.
There are probably hundreds of people out there that couldn't figure this
out and have given up all because they can't burn a boot loader either an
off the shelf avr ISP.

The solution proposed seems simple enough, let's make it happen!

Else anyone wanna show a noob how to compile the IDE?
Would live to learn some day.
Could use a Skype mentor or something.

Cheers all.
Thanks for the links, the info and for keeping up the fight Bill.
On 27/05/2015 11:39 am, "bperrybap" [email protected] wrote:

This isn't something that just broke. This issue has existed for MANY
years and still exists today.
So it isn't something that used to work that now doesn't.
I have IDEs all the way back to 0015 and they all have this issue; most
users don't see because they are not using the affected devices.
Ironically, it only affects the official atmel ISP programmers, not any of
the 3rd party programmers like the bootloaders, TinyUSB, or USBasp.

And yes it is a good topic for the Arduino bug tracker and for avrdude and
that is why I entered it in the Arduino bug list and on savannah tracker
over 4 years ago and it is still there today (It was imported into the
github issues when arduino was transitioned from Google Code to github)
And there were other reports of this issue in savannah several years
before I fully reported the issue on savannah.

I have fully documented the issue, I have provided a fix for avrdude and
and also provided a work around for the IDE.

Since I don't have update access to either repository I can't update the
code to either fix it in avrdude or add the work around to the IDE.

While the ideal solution would be to fix ardude, after more than 5 years,
it seems pretty clear that this may not ever get fixed in the main line
avrdude code.
So barring the Arduino team taking on delivering a patched avrdude, I'd
suggest that the IDE work around the issue by doing a bootloader burn
operation with a single avrdude command vs 2. The IDE can do the exact same
thing it does today, including the fuse operations in a single command, so
there is no reason to do it in two.

--- bill

—
Reply to this email directly or view it on GitHub
#2986 (comment).

[cmaglie]

@bperrybap
would you mind if I ask you how you will change the command line in platforms.txt to accomplish what you're saying (use one avrdude's command line instead of two)?

https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/platform.txt#L85

[bperrybap]

Cristian,
I'll need to go review the latest IDE code to understand how it is currently implemented and how it is using these bootloader enties. My suspicion is that the issue will likely be in the semantics of the "burn bootloader" operation that the IDE adopted.
I.e. the IDE is wanting to process the bootloader burn operation as multiple steps instead of 1.
(erase/program/burn etc.. Vs "burn" in one step)

So it may require some minor changes to the IDE as well to truly handle it properly and cleanly.
That said, more than likely I can come up with a temporary "kludge" that can combine a couple of these together in the platform.txt file to do it all in one avrdude command vs multiple without having to modify the IDE.

In other words, even if the preferred avrdude work around solution does require modifying the IDE, I'm pretty sure I could modify one of these burn bootloader entries to do it all in one step. Then patch the other entries to essentially be NOPs so avrdude is not called again.
It is ugly but that I think it might be a useful work around until the IDE can be modified, should the IDE need modification.

I'll go review the IDE code and get back with some additional information as I'm not sure what is needed until I go review the latest IDE code.

--- bill

[bperrybap]

Cristian, Does the Arduino team have any interest in shipping a patched version of avrdude to just solve the problem where it really needs to be solved?

Maybe you guys could put some pressure on Joerg to fix it since it it affects all the Atmel programming devices as Arduino is a pretty propular and visible user of the AVR chips and avrdude.

[cmaglie]

Hi Bill,

if the patch is simple (like adding a call to delay(...) at some point) we can handle it. The set of patch we keep on the official avrdude is here:

https://github.com/arduino/toolchain-avr/tree/master/avrdude-patches

if you can do a pull-request on that repository to add the patch we can include it in the next release
.

[bperrybap]

The avrdude patch is very simple. 7 lines of new code. in usb_libusb.c
A local declaration. A label, an if statement along with a delay and a goto.
(Yeah a goto, it keeps the coding very isolated, simple, and minimally invasive. If you look at the avrdude source code this exact same coding style/technique was used in many places in other modules to handle retries)
Here is the if block that gets added into usb_libusb.c:

  if(++tries < 30)
  {
        usleep(100000); // wait to allow device to be ready or a possible OS enumeration to complete
        goto retry;
  }

This polls the USB every .1 seconds for up to 3 seconds looking for the USB device.

Joerg didn't like the fix because it broke the way he was "polling" for USB devices on the USB. From my conversation with him it sounded like he was occasionally taking advantages of a undocumented "feature" of avrdude to detect the presence of certain USB devices. Adding this fix to the code would slow down what he was doing since it would wait for several seconds for a non existent device, so he didn't like it.

This added delay only happens when you are trying to use non existent devices. Normal users are not ever doing this. There is no added delay when avrdude is used normally and so users of Atmel devices like the MKII or the Dragon will see no added delays.
Also, given that avrdude slams the USB with reset, it is the only way to ensure that avrdude can see USB devices that do exist when back to back avrdude commands are done.

Cristian,
It may not be as simple as just fixing avrdude since there are distributions like Ubuntu/Mint etc... that end up creating their own "arduino" packages and use the standard avrdude vs the avrdude that you guys build/provide.
i.e. for completeness/robustness in all environments, it may also need some tweaks to the IDE so it works with older/unpatched versions of avrdude.

But for sure if you guys are up to accepting and shipping avrdude patches, I'll get the avrdude patch to you guys.

I'm not understanding what that patch tree is or how it works.
(I don't see any avrdude source code there)
I'll contact you directly and we can work out the best solution to finally get this fixed at least for Arduino users.

--- bill

[bperrybap]

OK, guys.
I'm looking at the latest avrdude 6.x source in the SVN tree.
They have changed the way this USB reset stuff works since 5.11.
avrdude used to reset the USB every time if the OS was not FreeBSD, which means that it was reset on MAC, Win, and linux.
Now the code will only reset the USB if the OS is linux.

The old libusb problem was that if you didn't reset the USB then libusb left the USB device in some sort of non working state and libusb couldn't talk to it anymore.
(at least that is what the comment said)

So if things were in that state, then I'm assuming that no amount of delay would help.
I'm not sure why this change was made since the 5.11 code, maybe libusb was fixed on some of the other OS's?
Maybe libusb now resets the USB when it closes/exits?

Anyway, I'd like to understand if this is now just a linux issue (as the latest code seems to indicate) or whether the Windows and MAC users are still seeing it as well.

In order to know, I'd like know the version of the avrdude tool that the IDE is using for those that are having an issue with this.

--- bill

[millerlp]

Output from the 2nd part of the bootloader burn process, after successfully burning the fuses in the first step:

D:\Arduino\arduino-1.6.4\hardware\tools\avr/bin/avrdude -CD:\Arduino\arduino-1.6.4\hardware\tools\avr/etc/avrdude.conf -v -patmega328p -cstk500v2 -Pusb -Uflash:w:D:\Arduino\arduino-1.6.4\hardware\arduino\avr/bootloaders/atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex:i -Ulock:w:0x0F:m 

avrdude: Version 6.0.1, compiled on Apr 15 2015 at 19:59:58
         Copyright (c) 2000-2005 Brian Dean, http:https://www.bdmicro.com/
         Copyright (c) 2007-2009 Joerg Wunsch

         System wide configuration file is "D:\Arduino\arduino-1.6.4\hardware\tools\avr/etc/avrdude.conf"

         Using Port                    : usb
         Using Programmer              : stk500v2
Error while burning bootloader.
avrdude: usbdev_open(): did not find any USB device "usb"

Arduino version 1.6.4 from arduino.cc
Windows 7 x64 professional, i7-3770
AVRISP mkII
This occurs when attempting to burn the included bootloader from arduino-1.6.4\hardware\arduino\avr/bootloaders/atmega/ATmegaBOOT_168_atmega328_pro_8MHz.hex

About three years ago when I originally got the AVR mkII working (under Arduino 1.0), I used the info and drivers listed in the first post from this thread: http:https://forum.arduino.cc/index.php?topic=118089.0 and the driver downloaded from http:https://mightyohm.com/blog/2010/09/avrisp-mkii-libusb-drivers-for-windows-7-vista-x64/ That arrangement worked fine up through Arduino 1.0.6, but started having this problem when I switched to Arduino 1.6.4.

Here's what the Windows device manager reports for the USB driver for my AVR mkII:

[millerlp]

Following up, bperrybap sent me a new modified version of avrdude to work with my windows 7 x64 installation of Arduino 1.6.4. I believe the modified version implements the brief delay between the two bootloader burning steps described in his post above. His new version fixes the issue I was having with the 2nd step of the bootloader burning process failing. My AVRISP mkII works as expected once again.

[bperrybap]

There is no blind delay between the 2 avrdude commands like what the IDE is currently doing.
avrdude is unaware that it may be executed more than once nor whether it is the first of more than one execution.

The very small amount of added code in avrdude polls for the USB device to be present for up to 3 seconds rather than looking just once. It is 7 lines of code that implements a loop around the existing code that waits 1/10 of a second if the expected device is not there and tries again, but then gives up after looking for 3 seconds. The advantage of this is that doesn't add any additional time to the device connection if it is not necessary.

Given the IDE is already doing a 1 second delay between avrdude commands the maximum polling time probably should be bumped to at least 4 seconds and possibly even 5 if the delay inside the IDE is removed.

The other alternative is to fix the IDE to not do 2 avrdude commands when burning a bootloader but rather do it all in a single command. If it were fixed this way, avrdude would not need to be fixed/patched and the burn would be just a little bit faster than it is now.

[per1234]

@bperrybap I'm interested in trying the patched avrdude as I also have the same error burning bootloader with AVRISP mkII via IDE 1.6.6 on Win7 x64 even though it works fine with IDE 1.0.6. Upload using programmer does work. Is it available for download anywhere? Thanks for your work towards fixing this problem.

[cmaglie]

@bperrybap
since you have a working patch I think that patching avrdude is the best way to go at this point. If you want to share the patch I can try to put it here https://github.com/arduino/toolchain-avr/tree/master/avrdude-patches so we can distribute it in the next release (or if you can do directly a pull-request on that repository it's even better).

P.S. sorry I forgot to answer your email!

[bperrybap]

That would be great. I'll share the patch or do a pull-request but where is the actual avrdude code that you guys are using? I looked in the toolchain-avr tree from the link above and didn't see it? Is it somewhere else or am I just missing it?

[cmaglie]

We use http:https://download.savannah.gnu.org/releases/avrdude/avrdude-6.0.1.tar.gz as source base.
The archive is downloaded by the build script avrdude.build.bash:

https://github.com/arduino/toolchain-avr/blob/master/avrdude.build.bash

BTW you can't call this script directly because it needs some dependencies compiled first. You should use one of the arch.arm.build.bash, arch.linux32.build.bash, arch.linux64.build.bash, arch.mac32.build.bash, arch.win32.build.bash.

[per1234]

I've created a workaround for this issue: https://github.com/per1234/Arduino-AVRISPmkII-fix that adds a new Programmer menu entry. It can be installed using Boards Manager or manually.

[per1234]

This issue was solved for me by the update to avrdude 6.3.0-arduino2 in Arduino AVR Boards 1.6.12. Note that there was a new AVRISP mkII issue introduced: arduino/avrdude-build-script#2.

EDIT: Using Windows 7 64 bit.
arduino/avrdude-build-script#2 has been fixed in Arduino AVR Boards 1.6.14.

[cmaglie]

Should be fixed with #5374.
Please reopen if the issue persists.

[bperrybap]

Where is the commit for the code that fixes this?
I would like to do an actual code inspection to see what was changed/fixed to see how this was resolved.

[facchinm]

Here you are https://github.com/arduino/avrdude-build-script/blob/master/avrdude-6.3-patches/60-avrdude-6.3-attiny85_delay_increase.patch

Sorry wrong link, the fix was in avrdude itself

[bperrybap]

That patch has nothing to do with this issue.
This issue relates to the way avrdude is using libusb. It resets the USB when it exits. When avrdude is immediately run again, the Atmel devices have not completed enumerating since a USB reset appears to cause a f/w reset in those devices so it is a few seconds before the device's f/w is back up and enumerated.
Because of this the 2nd avrdude command will not see the Atmel devices like dragon and mk2 since they have not re-enumerated yet.

Even though I expected no change from this patch, I went ahead and tested the 1.6.12 IDE using a Dragon.
And sure enough the problem still exists.
Here is the output from the second avrdude command that the IDE runs.

avrdude: Version 6.3, compiled on Sep 12 2016 at 17:22:50
         Copyright (c) 2000-2005 Brian Dean, http:https://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/home/bill/Documents/devel/arduino/arduino-1.6.12/hardware/tools/avr/etc/avrdude.conf"
         User configuration file is "/home/bill/.avrduderc"
         User configuration file does not exist or is not a regular file, skipping

         Using Port                    : usb
         Using Programmer              : dragon_isp
avrdude: usbdev_open(): did not find any USB device "usb" (0x03eb:0x2107)

avrdude done.  Thank you.

Error while burning bootloader.

After this failure, the Arduino board has no working bootloader as the chip was erased by the first/previous avrdude command that set the fuses.

I've been trying for years to get Joerg to fix this in avrdude as it is only a 7 line patch in the libusb code but he won't fix it.
The IDE could easily work around it by doing the bootloader update and fuse settings in a single avrdude command vs using multiple avrdude commands, but so far I've also been unable to get a work around in the IDE either.

It is amazing that this issue has been allowed to go so long without resolution, particularly since I have provided all the needed information to fix it or work around it about 5 years ago.

I don't know what else to do to get this resolved.
(I use my own patched avrdude)

The most ironic part of this, is that avrdude is broken for the official Atmel made ISP programmers. None of the other 3rd party programmers have this issue.

My preference would be to patch it in the version of avrdude that the IDE ships, rather than do a work around in the IDE, and also provide an AVR dragon ISP programmer types in the standard programmers.txt file included in the IDE.

What can I do to move this issue forward and get it resolved?