lock/unlock bits fail to verify with Atmel AVRISP mkII and Arduino AVR Boards 1.6.12/avrdude 6.3.0-arduino2 #32
Comments
|
Same issue with MiniCore(tested with ATmega328P and ATmega168 but all include MCUs are in patch 8996). Probably same issue with MegaCore(untested because I don't have the microcontrollers but the MCUs are in the patch) Probably same issue with MicroCore(untested because I don't have the microcontroller but the MCU is in the patch) |
|
Great! Now how do I apply this .patch file to the existing avrdude.conf files? Should there be a simple shell script to do all this, is the file executable from can the file be executed using avrdude or is this a copy/paste job? |
|
I've actually experienced the exact same issue with an STK500 starter kit i got from the university. Uploading worked fine if I used the regular stk500 protocol, bur returned the ´0xff != 0x3f´ error if i used stk500pp.. I reported a bug on this last year but there was no response |
|
I patched Arduino AVR Boards 1.6.12's avrdude.conf with patch 8996 here: https://github.com/arduino/avrdude-build-script/files/392783/avrdude.conf.txt. I had to add the .txt at the end so GitHub would let me attach it to the issue. This is what I did to apply the patch on Windows, should be similar on other OS but will need a different patch tool. I think git can do it. This was my first time using a patch file so there's probably a better way:
The --binary option was required because of the line endings. The patches of NEWS and ChangeLog files will fail, but those files needed to be there for the patch to continue. There were some changelog comments at the top of avrdude.conf that didn't patch correctly, probably because the patch is kind of old. Those should be doable by hand. |
|
I don't think I need to install GNUwin32, since I'm using a mac and got a full blown Unix terminal (with the patch command already there). I'm not home right now, but I'll have a look at this in the evening (should be in the middle of the night where you live). |
|
I agree, you definitely don't need to install the windows patch tool. I was just listing the process I followed. It's actually the middle of the night right now here(California, USA) but I'm a night owl. Hopefully it will add support for your starter kit also. I think that was the idea behind the change in AVRDUDE's behavior and this patch, to make the handling of the unused bits consistent. It's definitely causing a lot of breakage(see also arduino/Arduino#5175) but hopefully will be an improvement in the long term. |
|
Will this patch break backwards compability with older IDEs that uses avrdude 6.0.1? |
|
The patched avrdude.conf from Arduino AVR Boards 1.6.12 does break backwards compatibility: but that's because line 1071 is: Apparently that syntax is not compatible with avrdude 6.0.1-arduino5 but the patch doesn't add any of that, it only changes the lock bit read masks. If I copy the patch ATmega1284P lock bit read mask for ATmega1284P: to your avrdude.conf line 2430 and change the unlock_bits and lock_bits values for ATmega1284 in your boards.txt to: which, if I understand correctly, are equivalent to the previous values(0x3f and 0x0f) because only the unused bits are changed. I can use AVRISP mkII and USBasp to Burn Bootloader with both avrdude 6.0.1-arduino5 and 6.3.0-arduino2. I had previously thought this change was possible only because of a difference in avrdude 6.3 and that you'd have to add an avrdude tool to the MightyCore installation but this indicates that may not be the case and you can stick with the current system of just using whichever avrdude is currently installed for the Arduino AVR Boards version the user has. Of course that's not a very thorough test, I've only really checked this out with the Arduino AVR Boards 1.6.12/avrdude 6.3.0-arduino2 since I wasn't sure which approach you'd want to take with this. I tried applying the patch to your avrdude.conf and it doesn't want to work because it's an older version than the one from Arduino AVR Boards I patched. |
|
It works with Arduino as ISP using avrdude 6.0.1-arduino5 and 6.3.0-arduino2 also. For some reason my USBtinyISP has been failing verification of the bootloader lately so I wasn't able to test beyond that step with that programmer. It works intermittently with 512 byte bootloaders but anything larger almost always fails. I have a couple new ones on their slow way here from China. |
|
Great! I'm about to apply the patch! I'll be back with more info soon |
|
I'm quite sure I didn't succeed applying the patch. After following your instructions this is the output of the patch command $ patch --input=no-lock-byte-read-mask.patch --binary --output=avrdude.conf
patching file ChangeLog
Hunk #1 FAILED at 1.
1 out of 1 hunk FAILED -- saving rejects to file avrdude.conf.rej
patching file NEWS
Hunk #1 FAILED at 9.
1 out of 1 hunk FAILED -- saving rejects to file avrdude.conf.rej
patching file avrdude.conf.in
Hunk #1 FAILED at 1819.
Hunk #2 succeeded at 2424 with fuzz 1 (offset -902 lines).
Hunk #3 FAILED at 2607.
Hunk #4 FAILED at 2799.
Hunk #5 FAILED at 2991.
Hunk #6 FAILED at 3183.
Hunk #7 FAILED at 3340.
Hunk #8 FAILED at 3542.
Hunk #9 FAILED at 3750.
Hunk #10 FAILED at 3958.
Hunk #11 FAILED at 4152.
Hunk #12 FAILED at 4385.
Hunk #13 FAILED at 4547.
Hunk #14 FAILED at 4729.
Hunk #15 FAILED at 4914.
Hunk #16 FAILED at 5140.
Hunk #17 FAILED at 5331.
Hunk #18 FAILED at 5477.
Hunk #19 FAILED at 5630.
Hunk #20 FAILED at 5787.
Hunk #21 FAILED at 5947.
Hunk #22 FAILED at 6925.
Hunk #23 FAILED at 7137.
Hunk #24 FAILED at 7351.
Hunk #25 FAILED at 7563.
Hunk #26 FAILED at 7753.
Hunk #27 FAILED at 7942.
Hunk #28 FAILED at 8128.
Hunk #29 FAILED at 8310.
Hunk #30 FAILED at 9177.
Hunk #31 FAILED at 9367.
Hunk #32 FAILED at 9575.
Hunk #33 FAILED at 10746.
Hunk #34 FAILED at 10937.
Hunk #35 FAILED at 11141.
Hunk #36 FAILED at 11338.
Hunk #37 FAILED at 11525.
Hunk #38 FAILED at 11714.
Hunk #39 FAILED at 11902.
Hunk #40 FAILED at 12090.
Hunk #41 FAILED at 12244.
Hunk #42 FAILED at 12435.
Hunk #43 FAILED at 13859.
42 out of 43 hunks FAILED -- saving rejects to file avrdude.conf.rejAny ideas? If yours succeeded, maybe you could upload it here so I can add that one instead? |
|
I had the same problem. It's because your avrdude.conf is too old. The patch was successful on the Arduino AVR Boards 1.6.12 ardude.conf because it's more up to date. Here's the options I see:
I'm happy to help out with any of this but my ability to test is limited to the MCUs I have on hand(ATmega1284P, ATmega328P and ATmega168 are the ones relevant to your cores). |
|
I think option 2 is the best choice. A lot of users are still using older versions of the IDE. I've very little (ok, no experience) with the patch command, how it works (identifying what to change and what to leave) and how it can be done manually. I'd really appreciate some help with this one 😃 After the patched file is added I should be able to do this on the other cores as well. If I'm a bit late to reply is it because I'm on vacation, and doesn't got access to a computer all the time. I get all the notifications on my phone though 😉 |
|
Option 1 won't break backwards compatibility because avrdude 6.3.0-arduino2 will be installed with MightyCore regardless of the IDE version. The downside is that this means a larger install and duplicate tools. I'm hoping the Arduino developers will come up with a way that tools can be shared between cores without causing the sort of problems we're experiencing now but this will be tricky and any fix will only apply to future IDE versions. The MightyCore specific tools approach will be more of a hassle for manual installation because you will have to either include the tools in this repository to allow a installation via a single download or instruct the users to install the tools separately, adding to the complexity of the installation process. This situation has definitely been a project since I have quite a few different 3rd party boards projects I'm involved with. I haven't done any work on some of them yet because I'm still trying to figure out the best approach to fixing all this breakage while maintaining backwards compatibility. Throw in Eclipse Arduino plugin compatibility, etc. and it gets even more complex. |
|
The absolute best option would be to make sure all users runs the same version of avrdude. If the first option won't break backwards compatibility and force users to use "my" version of avrdude (in this case avrdude 6.3) then I think we should stick with this. I'm not a conservative person myself, and I think that new and better software is great! 👍 IIRC the avrdude executable When it comes to the tool dependencies I've decided to wait until the dust settles. There's a long going discussion, and dealing with the Eclipse add-on makes it even harder. Hopefully there will soon be a fix we all can agree on. |
|
I agree that is the best option. Maintaining backwards compatibility is very important in my opinion and I try to consider it with anything Arduino related I do. avrdude 6.3.0-arduino2 has already fixed one bug(arduino/Arduino#2986) I know of and I suspect another one as well(https://github.com/arduino/Arduino/issues/388)(EDIT: confirmed). It seems to be incompatible with USBasp using libusb-win32 drivers(arduino/avrdude-build-script#1) but that can be fixed by changing to a different driver and I'm hoping they will be able to fix it since the stock AVRDUDE 6.3 doesn't have that issue.. I'll work on this today and let you know when I have something ready for testing. |
|
Manual installation file for testing: https://github.com/per1234/MightyCore/archive/no-lock-byte-read-mask.zip Boards Manager URL for testing: https://raw.githubusercontent.com/per1234/MightyCore/add-avrdude-630-tool/package_MCUdude_MightyCore_index.json Note that similar changes to Arduino AVR Boards are being considered in arduino/Arduino#5202 but the developer has put it on hold while other options are considered due to the breakage it will cause for 3rd party boards. That's not an issue for MightyCore but it could be useful to see what solution Arduino comes up with. Changes
I tested:
Not tested:
Issues:
Potential changesA possible solution to issues 1-4 is to create a release script that downloads MightyCore and each build of avrdude and assembles an installation file for each OS which would be attached to the GitHub release. This would eliminate the need to have the avrdude tool in an OS specific folder so the use of If you want the tools folder organized differently that's doable, it just needs to be inside the avr folder, other than that there's nothing fixed, it doesn't even need to be in a tools folder, though that makes sense for consistency. I needed to give the Boards Manager installation's avrdude a unique name to avoid arduino/Arduino#5042. This issue has been fixed in the hourly build but that doesn't help for backwards compatibility. The current tool name is |
|
Thanks! I'll be home on sunday, so I will test all this when I get home. If everything works fine I'll add it to the repo 😃 |
|
An update on Arduino's approach to this issue(arduino/Arduino#5202): The developer was concerned about the breakage of 3rd party boards that it would cause so has completely reworked the PR with a patched avrdude what allows the stock fuse settings to verify. I haven't tested it yet. If that change is merged it would mean that the issue described here will only affect users with Arduino AVR Boards 1.6.12 installed, any previous or newer versions will work with MightyCore as it is now. I'm no 100% clear on why the behavior of avrdude was changed between 6.0.1 and 6.3 but there must have been good reason for making such a large change. I believe the motivation was to make the handling of unused bits consistent. Arduino's approach seems like a step backwards to me. The problem this will cause for MightyCore if my proposed changes are accepted is that we will be unable to use new avrdude versions from Arduino so will be either forced to always use avrdude 6.3.0-arduino2, build avrdude from source, or use the prebuilt stock avrdude images which don't have Arduino's other patches. |
|
Thanks! I'll tested your "patched" core (manual installation), and it works fine with IDE 1.6.10. I burned the bootloader (using an USBtinyISP) and uploaded a simple sketch to an ATmega32. I noticed though that the IDE chose gcc 4.8.1 instead of the latest one. I hope the Arduino devs are working on a solution that doesn't lock the user into having to use the patched avrdude that comes with the IDE. It's a fix, but a rather dirty one. |
|
All I want is the core to work with the latest version of the IDE without having to rely on some magical patch to make this working. Ideally this core should work with stock avrdude 6.0.1 and 6.3, but one can't get the best of both worlds.. |
That's not caused by this version of MightyCore. Now that the toolsDependencies entries for avr-gcc 4.8.1 have been removed, installing MightyCore will not cause it to be installed. However, if that version has been installed by a different core then it will always be chosen by the IDE, for MightyCore, Arduino AVR Boards, etc.
It's a minor difference in two lines of platform.txt but I agree. There is no documentation of how to add tools to a manual installation. The only core I found that used tools was Arduino-STM32 so I copied how they did it but they don't have a Boards Manager installation so it isn't an issue for them. This thread: https://groups.google.com/a/arduino.cc/forum/m/#!msg/developers/TDYnunLEqXU/w6jRV_FcBAAJ indicates there is a way to make it so that a single platform.txt can work for Boards Manager and manual installation:
But I haven't managed to get that to work. No matter where I put the tools folder and whether I add the builtin_tools_versions.txt or not {runtime.tools.avrdude-MightyCore} never gets defined. I think I just need to keep at it. It's very frustrating how poorly documented the Arduino IDE is. I shouldn't have to dig some comment up on a mailing list and do a zillion trial and errors to figure out something that the developer, who knows exactly how it works because he wrote the code, could have spent 2 minutes adding to the documentation. There are so many hidden features like this. The guy who wrote half this stuff doesn't even work for Arduino any more so there are probably features nobody knows about.
Actually that's what the Arduino developers are planning. They are going to revert to avrdude 6.0.1-arduino5 for the soon to be released IDE 1.6.11/Arduino AVR Boards 1.6.13 and then patch the avrdude 6.3.0 source so that it will work with the standard Arduino fuse settings and release that in Arduino AVR Boards 1.6.14. They're going to try to get the changes merged upstream in avrdude. I think the first attempt is done here: arduino/Arduino#5202 (comment) but it sounds like there are going to be some significant changes from that implementation. The discussion of the decision to revert the avrdude version here: arduino/Arduino#5021 (comment). I'm not sure what the Arduino developers plan to do to avrdude to make this work. I have to assume that the changes that the avrdude developers made between 6.0.1 6.3.0 were thoroughly considered since they represent such a large change. The purpose change the avrdude developers made was to add consistency with Atmel's specifications, I just get the feeling that any workaround the Arduino developers make will basically be working backwards away from that, essentially a hack, and won't have a chance of being merged upstream. I hope I'm wrong.
Well it depends on your definition of "work", right now the only thing broken is AVRISP mkII(and probably other stk500v2 programmers) support when used with one Arduino AVR Boards 1.6.12. This issue will probably not occur with future Arduino AVR Boards versions. So this issue is fairly limited in scope and the problems associated with fixing it may outweigh the benefits. On the other hand, the changes described here offer the added benefit of allowing you complete control of the tools your core is used with, instead of being at the mercy of whatever Arduino decides to unleash. This is the first step towards getting Eclipse support back, an avr-gcc tool would be the next step. The Eclipse plugin developer got a patreon sponsor to pay him to investigate the issue and took the time to actually understand the problem. He may decide he has no choice but to adapt to the solution that the majority of 3rd party boards have settled on(removing the toolsDependencies items). |
You have a point! I'd rather include my own version of avrdude and avr-gcc and not having to rely on what the Arduino team choose to do. I'd always struggle to make sure the core and the core tools (avrdude, avr-gcc) is up to date, but I can add these in my own tempo. |
|
So how do you think we should solve the different platform.txt issue for manual/boards manager install? Is it best to use the gh-pages to store all the boards manager related stuff, or should I create a new branch? It's easy to forget updating both branches when their content is almost identical. Is it possible to "link" two branches, e.g I update a file in one branch, and the file gets automatically updated in the other fork? |
|
The Windows version of avr-gcc 4.9.2-atmel3.5.3-arduino2 is 42MB compressed. I'm guessing the other versions are in the same ballpark. With the current manual installation system I'm using that would make for a much larger download. This would be improved by the release script I mentioned previously. Boards Manager will only download the version for the user's operating system and if the same version of avr-gcc has been previously downloaded then it will use the copy stored in Arduino15/staging/packages instead of downloading it again. While the release script would be the best system, another option is to manually assemble the installation files for each operating system to attach to the release. Unfortunately adding files to a release can't be done via pull request so that responsibility would fall on your shoulders. If you're not up to writing the script you could make an issue for it with a "help wanted" tag and maybe put the word out on the forum threads for each core also and then use the "wetware" script until some kind soul comes along to help out.
That's actually a big advantage of MightyCore having its own tools. With the current system of using whatever tool versions Arduino AVR Boards is using you have to do a bunch of testing as soon as Arduino updates to new versions. I think it was less than a day between the tools being added and the release of Arduino AVR Boards 1.6.12. The first you know of an incompatibility might be one of the users reporting the issue. With MightyCore specific tool versions you can update the tools when you are ready, test them at your own pace, and only release the new version when everything is in a fully working state. avr-gcc 4.9.2-atmel3.5.3-arduino2 has LTO but with the current system of using whatever version of Arduino AVR Boards tools the user has installed adding the flags to platform.txt to enable LTO will break backwards compatibility. If MightyCore had its own avr-gcc 4.9.2-atmel3.5.3-arduino2 tool then you would know that enabling LTO will work regardless of what Arduino AVR Boards or IDE version the user has.
I'm going to systematically work through every possible combination of tool folder location and structure today until I can get the IDE to define |
|
I've come to the conclusion that there's no way to get {runtime.tools...} values set for manually installed boards. It relies on the tool entries in the Boards Manager JSON files. Along the way I figured out a different way to use the same path value for Boards Manager and manual installations and thus not need to have different platform.txt files: The Boards Manager avrdude-MightyCore tool is located in the same place but manual install avrdude-MightyCore was moved to Since I can't use the The manual installation instructions have changed a bit since there are now two separate folders under the sketchbook affected. Since the path value in platform.txt contains the tool version it will need to be updated whenever you update to a new tool version. The tool download URLs in the beta testing instructions would also need to be updated. Boards Manager URL(v1.0.7-test2 only):Manual installation files:
Manual installation instructions:
|
|
It turns out there is an issue(arduino/Arduino#5173) with Arduino's build of avrdude 6.3.0-arduino2 that causes upload to fail when the IDE is started by opening a sketch(I think Windows only). I've been unable to reproduce this issue(may be Windows 10 only and I'm on Windows 7) and am not sure if it would occur with a tool installed via Boards Manager rather than the version included with the Arduino IDE. I saw a report on the forum today of someone experiencing the issue with Arduino IDE 1.6.9/Arduino AVR Boards 1.6.12 which makes me think there is a possibility the issue would affect a MightyCore avrdude 6.3.0-arduino2 tool. The flaw was caused by Arduino's build accidentally having an external dll dependency which is not found because starting the IDE by opening an ino file doesn't add the correct IDE folder to the path. I suspect the problem could be fixed by just adding that file(libusb-0.dll) to the tool folder but I can't confirm this since I can't reproduce the issue. If anyone reading this can reproduce arduino/Arduino#5173 and is willing to help out please comment. If the dependency issue can't be solved it doesn't necessarily rule out the idea of adding a MightyCore avrdude tool, I see a few alternative tool options:
|
|
I'm sorry I've been so late to reply, I'm still on vacation 👍 I'll have a look at it when I get home on Monday |
|
No worries, just enjoy your vacation! I don't think it's that critical anymore if the Arduino developers will just release Arduino IDE 1.6.11/Arduino AVR Boards 1.6.13, more of a long term possibility to consider. Even if only a learning exercise it's taught me what will be required to add LTO support to cores without breaking backwards compatibility, which offers more potential advantages than the avrdude update. |
|
BTW Arduino IDE 1.6.11 is out! It seems like they rolled back to Avrdude 6.0.1 |
|
The release of Arduino AVR Boards 1.6.14/Arduino IDE 1.6.12 has brought the return of AVRDUDE 6.3. The new avrdude 6.3.0-arduino6 is patched to deal with the issue of changed unused fuse bits handling causing incompatibility with previous fuse settings. Now when you burn bootloader to ATmega1284P with AVRISP mkII programer it verifies the lock bits successfully but with the following warning: So this is a great improvement over avrdude 6.3.0-arduino2 but I have already seen multiple reports from users scared by this warning(people frequently don't understand the difference between a warning and an error) in the 2 days since the release so I'm guessing you will be hearing about this from time to time. I'm not sure how earnest the Arduino developers are about eventually removing backwards compatibility for old fuse values or how soon that might happen. It may depend on whether something like their patch is merged upstream by AVRDUDE. |
|
Just going through some old issues here. Is there anything that needs to be done in order to close this? |
|
I haven't seen any move towards reverting Arduino's patch so this issue should only occur with that one bad Arduino AVR Boards version for the foreseeable future. The "scary" warning has also been removed. Unfortunately it doesn't seem there has been any progress on the upstream fix. |
…8b9a a367b8b9a Merge pull request #32 from cburstedde/feature-exact-timing e7f9313ce Merge branch 'master' into feature-exact-timing c24da8fcb Updated accuracy calculation 7efce6186 Replace bit_is_set with "regular" and operation 5fba4671d Minimal accuracy tweaks 0f33b77ce Merge pull request #31 from cburstedde/feature-exact-timing d10b60393 Update README 299220515 Exact or very accurate millis/micros/delay always 065732108 Non-functional tweaks 0dd91a679 Update README 25fad398a Add exact timing for 9.216 MHz 19b8514f5 Merge branch 'master' into feature-exact-timing 5d4ba89e8 Correct millis and micros for arbitrary frequencies 8913fb360 Add missing parentheses b622f9856 Add exact timing for 10 MHz 0333bcea5 Update README 5af5045c8 Add accurate timing for 16.5 MHz e318ce1ca Add exact timing for 6 MHz 0c0b4f3a8 Remove superfluous cast aeaadea0f Merge pull request #29 from cburstedde/feature-delayMicroseconds 4e74473d7 Merge pull request #28 from cburstedde/feature-correct-micros 6916530f2 Fix several corner cases in delayMicroseconds() 038385eea It makes a difference using unsigned math!! 912145b81 Go back to long multiply but still optimize 909105605 Use faster unsigned int multiply in micros() eeb6635e7 Merge pull request #27 from cburstedde/feature-exact-timing 21d1d6fa7 README typo 9be3a3e42 Disable alternate micros algorithm for powers of 2 bcd8baa5a Move timer0_exact static variable def into ISR 745508971 Rename correction #define and variable 9fef70e27 Reduce unnecessary long comparison to char 95166c10e Correct bad idea: access fract with interrupts off f64aa5d03 Remove unneeded unsigned char in micros() a91536407 White space in wiring.c f683310fa Make micros zero-drift based on exact millis b28acdb84 Make 25 MHz a supported clock frequency 2a6c810ce Comments and README edits 7cde04dd0 Merge pull request #26 from cburstedde/feature-delayMicroseconds 0172627e2 Merge branch 'master' into feature-delayMicroseconds 3b1142ffd Merge pull request #25 from cburstedde/feature-correct-micros e858df7d8 Merge branch 'master' into feature-correct-micros b32ca2bc5 Merge pull request #24 from cburstedde/feature-correct-millis 0205fd55b delayMicroseconds() safe for us == 0 and >= 24 MHz 032bed72f Statement on delayMicroseconds() in README afa0f8f69 Use 60398UL unsigned long constant 9b7291ae3 Add 22.1184 and 18 MHz cases to delayMicroseconds ec16def12 Add/edit comments for delayMicroseconds() 4a89b74ed Replace abs macro ... with a "safe" version of the original abs macro. Unlike __builtin_abs() this also deals with floats, which is pretty much required to ensure compatibility against the official Arduino core(s). 57b7486af Tune ppm values in README 059d20b18 Optimize away two increments from timing ISR 3d890c22d Improve micros() to 100 ppm for 7.37, 3.68, 1.84 d852091be Tiny README update 39112b389 Simplify millis calculation to fit into long int d1719372c Improve micros() accuracy for 14.7456, 12, 11.0952 84c8f335d micros() below crystal tolerance for 18.432, 20 MHz b8002ce05 Update README for new/improved micros() 239425178 Make micros calculation more efficient for 20 MHz d736735fd Add 18 MHz clock to micros() 21cf2177e Improve accuracy of 24 MHz micros() 3b9aa8990 Add 18 MHz clock to millis() calculation 65aa77f4d Fix timing error for non-power-of-two clocks 0091354f8 Add discussion of micros and delay to README af3b94c79 Non-functional clarification 2568a3f85 Add millis() discussion to README 56512e963 Add millis () correction to make 22.1184 MHz exact 2d42b729d Add 22.1184 MHz micros () correction 46fa6940c Prevent micros for 32 MHz to enter wrong case 49f5f250a Increase micros () accuracy for 18.432 and 20 MHz b51058fe1 Supply millis () correction for 24 MHz 993843d4d Add two odd frequencies 7.37 and 3.69 MHz 25c1c988b Correction makes millis() exact for several speeds git-subtree-dir: avr/cores/MCUdude_corefiles git-subtree-split: a367b8b9ab17653a379108e48d7696bf1c6ca336
Tools > Board > ATmega1284P
Tools > Programmer > AVRISP mkII(MightyCore)/AVRISP mkII(they are equivalent for Burn Bootloader)
Tools > Burn Bootloader fails with:
The explanation of the cause of this issue is described at arduino/avrdude-build-script#2
This issue will likely also occur for all MightyCore boards, all but ATmega16 have been modified in the patch for this issue, I don't find an entry for ATmega16 in the stock avrdude.conf file. I only have ATmega1284P to test with.
The solution which will still offer backward compatibility with previous Arduino AVR Boards versions requires defining an avrdude tool in the MightyCore Boards Manager JSON file. If you use avrdude 6.0.1-arduino5 then no further changes are required. If you use avrdude 6.3.0-arduino2 then the avrdude.conf patch found at https://savannah.nongnu.org/patch/index.php?8996 will need to be applied and
unlock_bitsandlock_bitsvalues in boards.txt must be updated. The avrdude tool will also need to be installed for manual installation.EDIT: platform.txt will also need to be modified to point to MightyCore's avrdude tool.
Another solution would be to just drop support for AVRISP mkII. The Atmel AVRISP mkII is no longer being made but there are still a lot of them around. The Olimex AVRISP mkII is still in production. I have only tested this issue with Atmel AVRISP mkII.
The text was updated successfully, but these errors were encountered: