Go Down

Topic: "efuse not defined" bug in 1.6.5 (more or less solved) (Read 1 time) previous topic - next topic

john1993

no luck in programming area maybe try here.

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.

thanks for the help.

DrAzzy

Make a new core with a platform.txt that doesn't refer to efuse, which the m8 doesnt have
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

john1993

#2
Jul 30, 2015, 06:49 pm Last Edit: Jul 31, 2015, 04:00 pm by john1993
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.

DrAzzy

#3
Jul 30, 2015, 10:25 pm Last Edit: Jul 30, 2015, 10:28 pm by DrAzzy
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



tools.avrdude.erase.pattern="{cmd.path}" "-C{config.path}" {erase.verbose} -p{build.mcu} -c{protocol} {program.extra_params} -e -Ulock:w:{bootloader.unlock_bits}:m -Uefuse:w:{bootloader.extended_fuses}:m -Uhfuse:w:{bootloader.high_fuses}:m -Ulfuse:w:{bootloader.low_fuses}:m

to


tools.avrdude.erase.pattern="{cmd.path}" "-C{config.path}" {erase.verbose} -p{build.mcu} -c{protocol} {program.extra_params} -e -Ulock:w:{bootloader.unlock_bits}:m -Uhfuse:w:{bootloader.high_fuses}:m -Ulfuse:w:{bootloader.low_fuses}:m


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....
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

john1993

#4
Jul 31, 2015, 03:22 am Last Edit: Jul 31, 2015, 03:46 pm by john1993
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:

Quote
tools.avrdude.erase.pattern="{cmd.path}" "-C{config.path}" {erase.verbose} -p{build.mcu} -c{protocol} {program.extra_params} -e -Ulock:w:{bootloader.unlock_bits}:m -Uefuse:w:{bootloader.extended_fuses}:m -Uhfuse:w:{bootloader.high_fuses}:m -Ulfuse:w:{bootloader.low_fuses}:m
into two:

Quote
tools.avrdude.erase.pattern="{cmd.path}" "-C{config.path}" {erase.verbose} -p{build.mcu} -c{protocol} {program.extra_params} -e

-Ulock:w:{bootloader.unlock_bits}:m -Uefuse:w:{bootloader.extended_fuses}:m -Uhfuse:w:{bootloader.high_fuses}:m -Ulfuse:w:{bootloader.low_fuses}:m
apparently a typo or that crlf vs cr thing again. mac/linux gang are amazing practical jokers.

DrAzzy

#5
Jul 31, 2015, 10:39 pm Last Edit: Jul 31, 2015, 10:42 pm by DrAzzy
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

tools.avrdude.erase.pattern="{cmd.path}" "-C{config.path}" {erase.verbose} -p{build.mcu} -c{protocol} {program.extra_params} -e -Ulock:w:{bootloader.unlock_bits}:m -Uefuse:w:{bootloader.extended_fuses}:m -Uhfuse:w:{bootloader.high_fuses}:m -Ulfuse:w:{bootloader.low_fuses}:m


to

tools.avrdude.erase.pattern="{cmd.path}" "-C{config.path}" {erase.verbose} -p{build.mcu} -c{protocol} {program.extra_params} -e

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
ATTinyCore for x4/x5/x61/x7/x8/x41/1634/828/x313 megaTinyCore for the megaavr ATtinies - Board Manager:
http://drazzy.com/package_drazzy.com_index.json
ATtiny breakouts, mosfets, awesome prototyping board in my store http://tindie.com/stores/DrAzzy

westfw

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:

C:\Program Files\Arduino\hardware\tools\avr/bin/avrdude -CC:\Program Files\Arduino\hardware\tools\avr/etc/avrdude.conf -v -patmega8 -cstk500v1 -PCOM6 -b19200 -e -Ulock:w:0x3F:m -Uhfuse:w:0xca:m -Ulfuse:w:0xdf:m -Uflash:w:C:\Program Files\Arduino\hardware\arduino\avr\bootloaders\atmega8\ATmegaBOOT.hex -Ulock:w:0x2F:m


john1993

#7
Aug 01, 2015, 02:43 pm Last Edit: Aug 01, 2015, 03:12 pm by john1993
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.

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.

john1993

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.

Go Up