burning bootloader for m8 in 1.6.5 gets "efuse memory type not defined for part ATmega8". any ideas how to fix that bug in the ide?
edit: thanks to drazzy hint i found a better fix. in this particular case simply deleting "-Uefuse:w:{bootloader.extended_fuses}:m" from platform.txt does the job. prevents setting efuse but not a problem for those guys working with m8 or m328.
maybe some other chips do need efuse in which case you can use the old platform.txt or an avrdude command. for us this was not necessary.
i lack experience with that level of arduino ide so any more details would be appreciated, ie what folders etc.
it is amazing that team ardu allows such goofs to persist with something as popular as ng (coming soon to a theater near you: The Chip That Wouldnt Die!!!). not interesting to ivory tower residents who prefer bleeding edge but lucky for the other 99% who appreciate old but cheap&proven tech.
You need to create a new arduino core, copying the existing default core to this new core in sketchbook hardware folder. Then in the new core, remove all the entries for everything other than the m8 from boards.txt (as these will no longer work after the change to platform.txt and will just clog up board menu). Then modify platform.txt within this new core and change
The m8 is a such a primitive chip; it's hardly surprising that not many people are using them anymore. It's a mega so old that even modern tinies outperform it on just about every metric. It's not like there's a big cost savings, since assembled pro mini clones with the 328p on them are only $2.xx on ebay, shipped, nanos ~$3....
i agree the cost of chinese pro mini, often as low as a dollar and change, is quite phenomenonal. in most cases even less than that of the ic alone. its true ng boards are extinct but ive been lucky last few years to obtain m8 chips for about 1/3 to 1/5 cost of m328. this means several m8 projects built for the cost of a single 328. the more expensive part has no advantage in about 90% of applications. certainly none in terms of speed performance.
anyway thanks to your hint i found a simpler fix by splitting this line from main platform.txt:
Uh... the problem is unrelated to crlf, nor is it a typo.
The problem is completely expected - the way it works, is that the IDE substitutes things into that pattern, and then executes it. (cmd.path points to avrdude). But AVRdude gets it, looks at it's config file, and sees the -Uefuse:w:... argument, and (quite correctly) errors, because the m8 has no extended fuses.
What's happening and why it appears to work is you basically changed that line from
The next line is treated separately - and since it is not a valid line line, it's ignored entirely.
As you can see, this isn't setting high or low fuses at all. In fact all it's doing is a chip erase cycle. When you do burn bootloader like that, all it's doing is erasing it. It will not set the low and high fuses to use the correct clock source, etc. Sure it doesn't error - but that doens't mean it's doing what you think it is. In fact, now, all burn bootloader is doing is writing the fuses and lockbits, when it runs the next command to write the bootloader:
tools.avrdude.bootloader.pattern="{cmd.path}" "-C{config.path}" {bootloader.verbose} -p{build.mcu} -c{protocol} {program.extra_params} "-Uflash:w:{runtime.platform.path}/bootloaders/{bootloader.file}:i" -Ulock:w:{bootloader.lock_bits}:m
You could just issue the appropriate avrdude command in a command-line window, depending on how comfortable you are with your OS. That's probably easier than creating a new platform file. If you have to do it often, stick it in a .bat file (or equiv.)
It will look something like this:
thanks for the explanation drazzy. i have better understanding now and you are right, my fix was not a complete fix at all. just masked the fuse error but does solve the immediate problem of flashing a bootloader.
DrAzzy:
The problem is completely expected -
...
AVRdude gets it, looks at it's config file, and sees the -Uefuse:w:... argument, and (quite correctly) errors, because the m8 has no extended fuses.
so the intent is to produce a programming environment designed to fail?
initial attempts creating new cores not fruitful so ive recommended these guys go with the batch file method. this is what i prefer for my own professional and hobby purposes using a simplified version of what westfw posted. that and my platform.txt edit got these guys going again. an additional level of complication but lesser of two evils.
best of all possible worlds would be for ardu team to get their act together and fix these "features" that prevent flashing a bootloader.
again, thanks to drazzy a better fix is here. simply deleting "-Uefuse:w:{bootloader.extended_fuses}:m" from platform.txt does the job. no bat file and since m8 is the only chip in use at that location a perfect solution.