Test programmer definition on hardware #1
Comments
per1234
added
Waiting For Feedback
|
I got an AVR Dragon and would be willing to test :)! |
|
Yay! I'll start working on this now and let you know as soon as I have something ready. |
per1234
removed
the
Waiting For Feedback
|
OK. I have something ready to test. This looks like a lot of steps but most of it is quick, simple stuff. I just like to be very clear in my instructions so there is no room for confusion. Please let me know if you have any questions. Test Burn Bootloader
The expected behavior is that the Burn Bootloader process will fail: However, if you scroll up the black console window at the bottom of the Arduino IDE window, You should see that two avrdude commands were run. The first command should have completed successfully and the second command was the one that failed with the above error. The trick to the workaround we are currently testing is that the commands normally run by the Arduino IDE in two parts:
are now being done all in the first command. So the bootloader is burned and the fuses are set and it doesn't matter that the second command fails because everything it normally does is already done. Test the bootloader:
Test Upload Using Programmer
Note that when you do Upload Using Programmer the bootloader is erased. After doing this, you will need to do another Burn Bootloader before you can go back to doing standard uploads. Upload Using Programmer should work properly, with no error. Now, I realize the situation with Burn Bootloader in this workaround is far from ideal. It's the best I can do from an easily installable 3rd party hardware package due to a quirk of the Arduino IDE (platform.txt associated with the selected board is used for Burn Bootloader, rather than the platform.txt associated with the selected programmer). This means that I can only affect the behavior of Burn Bootloader via the programmer definition, which doesn't give me much to work with. There are a couple of additional hacky aspects to this regarding the configuration fuses that are a bit more technical, which I can explain if you're interested in that sort of thing. My feeling is that a well documented hacky way of easily making the AVR Dragon work with the Arduino IDE is better than nothing. Even if we can't get any farther than making this work, I still think it will be worth the effort. However, there is the stretch goal of getting Arduino to officially support the AVR Dragon. If that happens, I will be able to make the necessary modifications to platform.txt and the spurious Burn Bootloader failure will not occur. The hacky workaround is the first step. If testing shows this works, we can proceed to the slightly more complicated testing of the true solution. It's also possible for 3rd party hardware packages to do the same thing I would like to do to Arduino AVR Boards to offer AVR Dragon support for their boards. My initial investigation of this was with the goal of getting that done in the popular MCUdude cores but that ended up not happening. |
per1234
added
the
Waiting For Feedback
|
Hey there, got a first test setup: |
|
Ha, perfect, I got something nice! Burn bootloader: Normal Upload (but the AVR Dragon is used) Upload with programmer Option I changed the used pin during the uploads (did two uploads with the upload only option, changing the pin, and another upload with the upload using programmer option in the arduino, also changing to the third pin - everything worked right out of the box! Also, the error on burning the bootloader came up, as you suggested. Very fine work! 👍 |
|
Hey, good work on fixing the driver issue. I was just typing out a recommendation to use Zadig. I love that program! I had that exact problem with my Atmel AVRISP mkII after using it with Atmel Studio. That programmer has the similar issue to the AVR Dragon. In the case of the AVRISP mkII, the problem was solved for me either by using avrdude 6.3.0 or changing from libusb-win32 to libusbk (using Zadig). Some other people have claimed those solutions don't work for them with the AVRISP mkII and also have said they don't work for the AVR Dragon. The fix I would like to make to Arduino AVR Boards would also solve the issue for AVRISP mkII for good (at least when using Arduino AVR Boards). Regarding your Burn Bootloader results: How long does it take to do the spurious failure of the second step. From the output, it looks like avrdude keeps retrying. On the AVRISP mkII, the second command fails instantly. It would be very inconvenient if the failure of the second command causes a long delay of Burn Bootloader with the AVR Dragon. Regarding your normal upload results: Unfortunately, the ATtiny85 board definition you're using does not really use a bootloader (it does burn a dummy bootloader file just to appease the IDE's process) and it automatically does the equivalent of an Upload Using Programmer even when you do a standard Upload. For this reason, the ATtiny85 is not ideal for testing purposes. Do you happen to have something like an ATmega328P board on hand to test with? This all looks very promising. I'm actually quite surprised that the results were so good on the first test, considering I'm essentially working blind. I would like to get that normal upload test done, after which we can proceed to test the ideal solution. I notice that the ATTinyCore you're using for your ATtiny85 has its own AVR Dragon programmer definition and that the issue we're working to solve has been discussed there (SpenceKonde/ATTinyCore#136 (comment)). I will probably submit a proposal to make the ideal fix to that repository if the test reveals it will work. Maybe I'll have better luck there than I did in the MCUdude cores. I have done a bit of work on ATTinyCore in the past. |
|
Regarding the first bootloader burn: Did not take long, so no problem there :) Yeah got an 328P here. Upload 1: Upload 2: Upload with Programmer: Everything went very fast and worked out! Same test as beforehand - no problems whatsoever! :) Yeah it would be awesome to fix ATTinyCores problem as well, tend to use them from time to time and really a nice package :). something else you need :)? |
|
Thanks for getting out the ATmega328P. I'm glad to hear the Burn Bootloader delay I feared is not a thing. The normal uploads you're doing are still the equivalent of Upload Using Programmer. The reason is the atmega hardware package you're using does the same thing as the ATTinyCore's standard ATtiny85 board definition where it turns Upload into Upload Using Programmer. Upload Using Programmer will work regardless of whether the bootloader is working. Upload Using Programmer erases the bootloader so when you're doing that the purpose of Burn Bootloader is just to set the fuses according to the definition of the board you have selected from the Tools menu (that's all it's doing with the standard ATTinyCore ATtiny85 board or the atmega boards). What I need is for you to do an upload to the ATmega328P over a serial connection, as this is the way to verify the burned bootloader is working. This is how people normally upload to the regular Arduino boards like the Uno. The Uno has a USB to TTL serial adapter chip (ATmega16U2 on the official Uno or CH340 on the Chinese version) right on the board that creates a virtual COM port on your computer when you connect the board to the computer with a USB cable. Do you have a board with the USB to TTL serial adapter on board (e.g. Uno, Nano, Mega, Leonardo, Pro Micro, etc.), or a separate USB to TTL serial adapter board or cable you can connect to the ATmega328P? |
|
Burning Bootloader with AVR Dragon to an ATMega328P Arduino Style Board (with external 16 MHz Resonator) via the ISP Interface: Uploading via TTL Serial Uploading via TTL Serial 2nd Time, other blink parameters Upload using AVR Dragon Worked out :)! |
|
Thanks! That's exactly what I needed to make sure it's 100% working. Are you willing to continue with testing of the ideal solution? I will provide a hardware package with an ATmega328P board definition you can use with the hardware from the last test. That package can be installed, updated, and removed via Boards Manager so it should be pretty painless. |
|
Sure thing, I would do that :) |
|
The ideal system test is ready for you: Test Burn Bootloader
Test the bootloader:
Test Upload Using Programmer
Note that when you do Upload Using Programmer the bootloader is erased. After doing this, you will need to do another Burn Bootloader before you can go back to doing standard uploads. |
|
Hi. I left out an important step in the instructions above (selecting the Arduino/Genuino Uno board from the "Single Command Burn Bootloader Demo" section of the Tools > Board menu). I have now updated the instructions above so they are now correct. Sorry for any confusion. |
|
Worked perfectly, awesome! Complete logs: Test Burn Bootloader Test the bootloader 1: Test the bootloader 2: Test Upload Using Programmer: |
|
Thanks for the testing! Looks like the ideal solution is fine. I suspect it may be a bit of a struggle making the case for changing such a fundamental part of the system (even though that change is very simple) just to add support for an outdated programmer. However, the Arduino developers haven't outright rejected any of the requests for Dragon support and ATTinyCore went ahead with adding partially broken Dragon support so I think it's worth a try. I'm sure there are a lot of AVR Dragons out there in the world and I'd love for people to be able to use them with the Arduino IDE. Even if the ideal solution proposals fail, we will still have accomplished something by providing some level of support via this repository.
I think it would be great. It especially makes sense for this repository to offer as much Dragon support as possible. I have added two new programmers to the InoAVRDragon package in the 0.1.0 release:
You can update to InoAVRDragon 0.1.0 like this:
Now run the usual tests after selecting Tools > Programmer > AVR Dragon HVSP mode (workaround) and Tools > Programmer > AVR Dragon PP mode (workaround). Thanks! |
|
PP Mode burning bootloader directly goes into error mode: With Atmel Studio 7 I can however read and erase the chip with (HV)PP, so the bug must be on our site :( Did not try HVSP, as wiring for HVPP is a serious nightmare and I do not want to disconnect anything until HVPP is working... ( https://www.microchip.com/webdoc/GUID-04E3421E-81C3-4E6C-BD29-9E1A7BAEBA7E/index.html?GUID-0FC53DF1-7D1A-4790-A83F-EE7F4C2FFC00 ) |
|
Oops. Caused by a dumb mistake on my part. I'm working on a new release now. |
|
OK, version 0.1.1 is now available via Boards Manager. You can install it via the same update procedure as 0.1.0. Hopefully things will go more smoothly this time. |
|
Mh, very weird: And it did not work, no bootloader on the chip afterwards |
|
I did find a report of a signature mismatch error with the Dragon that was solved by setting the bit clock to 5 us via the |
|
Sorry I had no time during the week, so I just came in testing. Sadly, no luck: I was especially cautious to not to touch any wires - and I switched back to Atmel Studio 7 - could read the chip successfully in that configuration and wiring, but only got that error in Arduino :(. Sorry for the bad news :(! |
|
I tested it with B8, that worked better, but I think its actually trying to push data too fast. Maybe an error in avrdude itself? |
|
Sorry to hear it's still not working. Thanks for sticking with me on the testing.
The If you want to give it a try with the official AVRDUDE:
|
|
A lot better - but still not there yet. |
|
Well, NICE! |
Great! Would you mind testing with the Arduino IDE again with the new power configuration? I suspect we'll be back to the same libusb0-dll error, but it's best to be certain. I believe this error is caused by a change in how AVRDUDE handles unused fuse bits. This change broke compatibility with the fuse values that worked in AVRDUDE versions previous to 6.3.0. That caused a lot of problems in Arduino land so Arduino's version of AVRDUDE is patched to also work with the old values. The only difference between 0xff and 0x3f are bits 6 and 7, which are unused, so the two values are functionally identical. |
|
Well, it started off with the same old error about libusb0-dll, but after replugging it a few times, it somehow worked. There is something really sketch between driver and the old avrdude version. I was able to complete all tests successfully, however, I had to try and try again / replugin etc. So patience and a good powersource should be needed... However, I think it is more of a driver and avrdude issue: Reason: I could use the AVRDragon with its original Atmel Driver from Atmel Studio 7 without these glitches. So something is not quite there yet, but a new avrdude version for Arduino would be already a good step in the right direction, I presume. Bootloader with -B3Uploadtest 1 with Serial Uploadtest 2 with Serial Upload with AVR Dragon Replug and try again And again.... |
|
Tried it again with PP: With a higher quality, powered USB 3 hub - burning the bootloader only with a AVRDRAGON: Uploading using serial on target system, test 1: Uploading using serial on target system, test 2: Uploading using the AVRDragon -> tested afterwards in target board successfully Second Test, ATTiny85 with HVSP using the ATtiny Microcontrolers package (not the ATtinyCore, as this got its own dragon definitions, which I tried to ignore here!)I went ahead, set the RST DISABLE fuse so that the RESET pin of the ATTiny could not be used for RESET/ISP programming again and I switched back to Arduino, tried to HVSP programm it (which should be the only way working) Everything worked out! This concludes my testing. I would let the B3 option in, I think it does not hurt here. From my point on, I would advise to actually release this package, maybe with the informations found - giving the ISP option free as "working" and the PP and HVSP option as "depending on a good usb hub with external power supply and short wiring". However, in the future, new avrdude versions would be advisable and probably also decrese problems. Thanks for your awesome work! |
|
Great! I'm definitely anxious to publish the package.
Why do you recommend Some of the MCUdude hardware packages come with "slow" programmer definitions with |
|
Hi there |
per1234
removed
Help Wanted
|
I have now made the repository public. Note that the Boards Manager URL has changed to: As soon as I get some more free time, I'll submit some pull requests to see if I can get anyone to go for the ideal solution. Thanks so much for your assistance nmaas87! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This issue is for discussion related to the testing.
I don't own an AVR Dragon so I am unable to test the definition.
Some time ago, @nmaas87 mentioned they might be willing to help with this (https://github.com/arduino/Arduino/issues/650#issuecomment-443155601).
@nmaas87, if/when you have a little spare time to work on this project. Please comment here. Thanks! I don't have anything in the repository yet because it's not worth that effort without the ability to test, but I have already worked on this in the past so I should be able to quickly get something up ready to test. I'm hoping to set this up as something installable and updatable via Boards Manager. There is a quirk to the Arduino IDE that may be problematic for that but I don't remember how that impacts this particular project. If Boards Manager installation is not possible, testing will still only require pasting a bit of text into the programmers.txt file in your Arduino AVR Boards installation.
I made the repo private for now since I prefer to publish things after they're in a somewhat workable state.
I also still have some hope that this work can get pushed directly into Arduino AVR Boards, rather than requiring a 3rd party solution. I want to wait until I can confirm this is even possible before I make that proposal to the Arduino developers.
The text was updated successfully, but these errors were encountered: