I'm quite a new user on this forum and I kindly request the support and advice from the community, for a point that has been puzzling me for days.
I have designed a custom PCB around an ATMEGA328P-AU chipset.
The configuration is 16Mhz 5V, similar to the Pro Mini I use to behave as the ISP programmer.
I want to burn the arduino bootloader but I have a weird result.
I use the version 1.6.10 of the Arduino IDE.
When I upload a sketch (let's say for instance the Blink example) to the Customized PCB through the Pro Mini, it is ok. (option upload with a programmer).
The LED blinks well which indicated that the chipset is OK and their are no issues with regards to the wiring or the 16Mhz external oscillator.
But at this stage, There is no bootloader flashed in the 328P itself.
By the way, I can set fuses via AVRDUDES without any problem.
As soon as I want to upload the bootloader from the IDE (following the process as I have done it many times for other 328P chipsets), I have got an error message from the avrdude engine.
Here is the result :
Writing | ################################################## | 100% 0.02s avrdude: 1 bytes of lock written avrdude: verifying lock memory against 0x3F: avrdude: load data lock data from input file 0x3F: avrdude: input file 0x3F contains 1 bytes avrdude: reading on-chip lock data: Reading | ################################################## | 100% 0.01s avrdude: verifying ... avrdude: 1 bytes of lock verified avrdude: reading input file "0x05" avrdude: writing efuse (1 bytes):
_Writing | ***failed; _ ################################################## | 100% 0.13s avrdude: 1 bytes of efuse written avrdude: verifying efuse memory against 0x05: avrdude: load data efuse data from input file 0x05: avrdude: input file 0x05 contains 1 bytes avrdude: reading on-chip efuse data: Reading | ################################################## | 100% 0.01s avrdude: verifying ... avrdude: verification error, first mismatch at byte 0x0000
0xfd != 0x05* avrdude: verification error; content mismatch avrdude done. Thank you. Erreur lors de la gravure de la séquence d'initialisation.
THe process stops before writing hfuse and lfuse...
I tried several values for efuse via avrdudes but keeps on showing this...
Programming through an ISP programmer erases the bootloader. The only instruction that you have over ISP to erase any flash is the chip erase command, which erases the whole flash (this is tied into Atmel's lockbit system of securing code), so uploading the sketch erases the bootloader.
Normally you don't have any reason to use a bootloader if you're programming over ISP - and if you're using a bootloader, you don't have to program over ISP.
The error is a problem related to the change in avrdude version that came with 1.6.10 and avr board package 1.6.12 (they go together - the two use different numbering), one of several major issues - they treat unused bits differently now. I forget the exact fix to resolve this specifically (other than the brute force fix of uninstalling 1.6.10, blowing away c:/users/(username)/AppData (hidden)/Local/Arduino15 and reinstalling 1.6.9 and not choosing to update the boards.)
Thanks a lot for your help.
As you indicated, I came back to version 1.6.1 and.... It worked fine
as we say in France : It's in the old pots that one can make the best soups
I agree that the best solution is to go back to an Arduino AVR Boards version less thatn 1.6.12, though I think all the way back to 1.6.1 is a bit excessive, there might be a bit too much rust on that pot. However, just in case anyone is curious or actually wanting to use the new avrdude version, here's the fix: Set unused bits of extended fuse to 1 by descampsa · Pull Request #5182 · arduino/Arduino · GitHub.
Because of this issue and a couple others, the next Arduino IDE/Arduino AVR Boards version will revert to the old avrdude version(6.0.1-arduino5) and the Arduino developers plan to release a new version of avrdude 6.3 patched so that the traditional Arduino fuse values will still verify probably in Arduino IDE 1.6.12/Arduino AVR Boards 1.6.14.
I'm wondering if the Arduino IDE should be tested, using a fairly large set of test cases designed to test that old existing features still work. Before sending the software out the door. Something kind of formal, with documentation and checklist. For example, burning a bootloader on an Uno using another Arduino as ISP may be a test case. I think in industry that is called regression testing.
dmjlambert:
I'm wondering if the Arduino IDE should be tested, using a fairly large set of test cases designed to test that old existing features still work. Before sending the software out the door. Something kind of formal, with documentation and checklist. For example, burning a bootloader on an Uno using another Arduino as ISP may be a test case. I think in industry that is called regression testing.
This issue demonstrates that they don't even do the most minimal amount of testing. They jump from avrdude 6.0.1 to 6.3.0 and don't even take the time to do a single Burn Bootloader on an Uno? This issue occurs using any programmer, not only Arduino as ISP. I wouldn't do a release of one of my amateur public projects that nobody else even uses without more thorough testing than that. It was a matter of hours between the new tool versions being merged and the release of the new IDE version. I saw it happen, was excited about the new tools and was planning to download the hourly and do a bunch of tests to see the effect on the 3rd party cores I'm involved with but had to wait until after midnight when I have unlimited data usage before I could download. By the time I had a chance to try it out they had already done the release.
There was a test build for the PR available for a while, though they did a bunch of changes minutes before the merge. The community also failed on this one, there were a lot of people commenting on the PR and obviously none of them did the minimal testing of avrdude either but the developers get paid for this stuff. I have trouble keeping up with all the test builds because I never know if the PR is going to be merged or abandoned or changed so much that my testing effort is wasted so I usually just try to stay current with the hourly unless the PR is something I'm directly involved in. It would be nice if they'd do an upcoming release notification so that all the interested parties would know they need to do some testing before the release.