Hope you can help me solve a frustrating problem I'm having no luck with at all.
I'm trying to upload the following simple sketch to an ATTiny841 breakout board:
const byte Led = 1;
int ledState = LOW;
unsigned long previousMillis = 0;
const long interval = 1000;
void setup() {
pinMode (Led, OUTPUT);
}
void loop() {
unsigned long currentMillis = millis();
if (currentMillis - previousMillis >= interval) {
previousMillis = currentMillis;
if (ledState == LOW)
ledState = HIGH;
else
ledState = LOW;
digitalWrite(Led, ledState);
}
}
I am using the 841 cores from here:
and have double and triple checked that all the files are located exactly where the README.md file says they should be.
I have used a slightly earlier version of this core before and been able to upload to the breakout board successfully. However, since my pc has been "upgraded" to Windows 10 and I am now using IDE 1.6.5 I can't seem to upload at all.
The error message I'm getting (and its the same message whether I use a USBASP or use a UNO as ISP) is too big to reproduce in the text of this message, so I've attached it. I've also attached a screenshot to show the tools menu selection being used, although I have tried a whole load of variations, all of which, apart from the illustrated settings, simply returned the message:
Error while uploading: missing 'program.tool' configuration parameter
By the way, I also got that message when using USBasp (ATtiny Modern) as programmer.
It seems to my untrained thought that the Avrdude.cfg file in "C:\Users\Bernie\Documents\Arduino\hardware\arduino-tiny-841" is just not being seen.
I've just corrected the issue with programming over USBAsp. Minor oversight on my part (since i usually use them with bootloader, I hadn't noticed it didn't work for programming) - forgot to copy over some parameters.
You must use the ATTiny Modern programmers. For reasons unclear (not sure if bug or feature), only programmers defined by the programmers.txt that comes with the core will use the avrdude.conf pointed to by platform.txt.
Redownload ave reinstall core (you must restart ide too). I fixed the problem with program.tool right before my last reply - I'd left out a few required parameters for programming.
Change was in programmers.txt, so if you prefer, you can just update that file with new version.
Replaced programmers.txt and it's all now uploading perfectly. You've saved my sorry backside thats for sure. I've got 100 841 based boards being manufactured and the only way to program them is via ICSP so I was beginning to panic!!
Can you please describe "ATTiny Modern" and ATTiny Classic" programmers?
Is there something online which describes how to make them or what makes them different? Is it just a software thing on the IDE side?
DrAzzy:
You must use the ATTiny Modern programmers. For reasons unclear (not sure if bug or feature), only programmers defined by the programmers.txt that comes with the core will use the avrdude.conf pointed to by platform.txt.
Well , he explain reasons, but i think it is more like bug, if platform.txt in custom core point to something , that must be used without adding anything else.
We should declare bug to IDE team.
The only thing about them that's different is that they're described by the programers.txt included with the core. They're otherwise the same as those normal programmers - and the name is different so you can tell them apart.
The reason this is necessary is that platform.txt (or parts of it) are ignored for programmers other than those included in the core's programmers.txt; the only way I can make it use the correct avrdude.conf is by pointing to it in platform.txt and then including duplicate programmer entries, which i postfix with ATTiny Modern or ATTiny Classic.
I can't tell people to change the systemwide one, either - beyond any other ideological arguments, it's installed under program files for many users, so modifying it is difficult due to Microsoft User Account Control File and Registry Virtualization (which behaves differently on each of the 4 most recent versions of windows, and on each version, several different behaviors (some of which involve it appearing to be editable, but not actually being edited) are possible depending on windows settings - so it's impossible to write comprehensible instructions for how to do that.
Something has gone awry with my programming of ATtiny841s again! I successfully programmed a batch of 20 or so ATtiny841 based boards at the time of my last posting on this subject after DrAzzy solved the problem (posts #3 and #4 in this thread).
I'm now trying to program another 20 boards (all made at the same time as the rest) using exactly the same method and equipment (USBASP) as before but now they won't program >:( . The error message I get, whether "burning bootloader", to set the fuses for the clock at 8MHz (internal), or simply trying to upload any sketch is the same. Here's the "burn bootloader" mesage:
Arduino: 1.6.5 (Windows 8.1), Board: "ATtinyx41, ATtiny841, 8 MHz (internal), B.O.D. Disabled"
C:\Program Files (x86)\Arduino\hardware\tools\avr/bin/avrdude -CC:\Users\Bernie\Documents\Arduino\hardware\arduino-tiny-841\avr/avrdude.conf -v -pattiny841 -cusbasp {program.extra_params} -e -Ulock:w:0xFF:m -Uefuse:w:0xFF:m -Uhfuse:w:0xD7:m -Ulfuse:w:0xE2:m
avrdude: Version 6.0.1, compiled on Apr 15 2015 at 19:59:58
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
Copyright (c) 2007-2009 Joerg Wunsch
System wide configuration file is "C:\Users\Bernie\Documents\Arduino\hardware\arduino-tiny-841\avr/avrdude.conf"
Using Port : usb
Using Programmer : usbasp
Setting bit clk period : 5.0
AVR Part : ATtiny841
Chip Erase delay : 15000 us
PAGEL : P00
BS2 : P00
RESET disposition : possible i/o
RETRY pulse : SCK
serial program mode : yes
parallel program mode : yes
Timeout : 200
StabDelay : 100
CmdexeDelay : 25
SyncLoops : 32
ByteDelay : 0
PollIndex : 3
PollValue : 0x53
Memory Detail :
Block Poll Page Polled
Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack
----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
eeprom 65 6 4 0 no 512 4 0 4000 4500 0xff 0xff
flash 65 12 32 0 yes 8192 16 512 4500 4500 0xff 0xff
signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00
lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00
calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00
Programmer Type : usbasp
Description : USBasp, http://www.fischl.de/usbasp/
avrdude: set SCK frequency to 187500 Hz
avrdude: error: programm enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude done. Thank you.
Is there anything there that would indicate where the problem lies?
The only thing that seems different from last time is that there is a COM port listed (see attached jpg). I don't think I remember seeing this before, but it makes no difference whether the entry is checked or not.
I also tried programming using a UNO as ISP, both on the target boards and an 841 breakout board and that gives the error message attached below (too large to put in code tags).
I haven't moved any of the core files so does anyone have any ideas as to what may have changed?
Hm, that should work - are you using an up-to-date version of the core? I've gone through a few iterations of methods to get the IDE to use the correct version of avrdude.conf (which is the cause of the issue with arduinoasisp)....
Are you sure you have the wiring correct? Typically "target device not responding" indicates a wiring problem... Check for things like ISP headers on wrong side (hence mirrored) or rotated 180 degrees.
Well, thats odd. I rechecked the wiring over and over and found no errors, but just in case I made up another lead from the USBASP to the programming probes. This time, the boards program ok - using either the new OR the original cable! If that isn't odd enough, I still can't successfully set the clock speed using the "burn bootloader" - I still get the same error message.
I really can't get my head around what's happening here. If you want guys, I can post up a photo of my wiring connections tomorrow if you think it may help solve the riddle!
STDummy:
If that isn't odd enough, I still can't successfully set the clock speed using the "burn bootloader" - I still get the same error message.
Which error is that? If it's the one in error.txt, that indicates you're either using an old version of the core, or have selected a programmer that doesn't have "ATTiny Modern" after it.
Making this (picking up the right version of avrdude.conf) work properly didn't go smoothly, and I don't know that I had it sorted out 100% when you were working with it last.
Yes, its the same error as in the error.txt message I posted yesterday.
I downloaded the latest cores and reinstalled them to no avail. I did get a little confused by the installation procedure I must admit because I think the screenshot you have there of the directory structure shows different directory names to those I ended up with.
I'll reinstall from scratch again when I get home from work, but in the meantime I'm going to try and set everything up on my work pc to see if it works from that. I'll take some screenshots of the directory structure after, perhaps you could take a look and spot anything untoward?
How do I get the url into the boards manager btw?
Many thanks for your help and hard work with this DrAzzy, its most appreciated!
I've worked out how to get the url into the board manager (via preferences) but the cores don't appear. I get a message "Error downloading http://downloads.arduino.cc/packages/packages_index.json" and it doesn't seem to add any other cores. Uninstalling, wiping the registry and reinstalling everything (including the IDE) doesn't change that message.
I think I'm beginning to regret choosing the ATtiny 841 ! Apologies for my lack of progress!
At my work pc, under Windows 7, I've done a fresh install of the IDE (1.6.5) and the latest 841 cores, made sure my USBasp driver is the latest available and attempted to load a sketch to my 841 breakout board. Result? The following error message (the same if set to 1 MHz (internal)):
Sketch uses 912 bytes (11%) of program storage space. Maximum is 8,192 bytes.
Global variables use 15 bytes (2%) of dynamic memory, leaving 497 bytes for local variables. Maximum is 512 bytes.
avrdude: set SCK frequency to 187500 Hz
avrdude: set SCK frequency to 187500 Hz
Any attempt to change the internal clock frequency using "burn bootloader" gives
Arduino: 1.6.5 (Windows 7), Board: "ATtinyx41, ATtiny841, 8 MHz (internal), B.O.D. Disabled"
avrdude: set SCK frequency to 187500 Hz
avrdude: set SCK frequency to 187500 Hz
avrdude: set SCK frequency to 187500 Hz
avrdude: error: programm enable: target doesn't answer. 1
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
Error while burning bootloader.
This report would have more information with
"Show verbose output during compilation"
enabled in File > Preferences.
Connections are all good. It seems I get different error messages depending on what pc I'm using. This (work) pc seems to cause a problem with SCK frequency - what controls that?
Bernie
PS Just turned on verbose output to see if there were any clues in the error messages and wtf, it uploaded !! Just what is going on???? It STILL won't "bootload" though.....grrrrrr!!!
Have you by any chance updated the firmware on your usbasp? That caused problems for someone else. Mine complain that they can't set the frequency but work correctly.
As for the problem with bootloading, I'm just baffled. That's all within the ide, and I can't figure out why it would be ignoring platform.txt - it should be using the avrdude.conf that came with the core, and that's what it does on all three of my computers, but yours is using the default one...
No, I've not updated the firmware. Its never been changed.
The only thing that is different, so far as I am aware, is the Java environment, but that shouldn't affect anything should it? I am really puzzled (and annoyed!), that it seems to need several (read a dozen plus) upload operations, and then the "system" seems to suddenly understand what's required of it!
This is the platform.txt file that is located in my \Documents\Arduino\hardware\arduino-tiny-841\avr directory:
# Arduino AVR Core and platform.
# ------------------------------
# For more info:
# https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5---3rd-party-Hardware-specification
name=ATtiny Modern
version=1.0.5
# AVR compile variables
# ---------------------
# Default "compiler.path" is correct, change only if you want to overidde the initial value
compiler.path={runtime.tools.avr-gcc.path}/bin/
compiler.c.cmd=avr-gcc
compiler.c.flags=-c -g -Os -w -ffunction-sections -fdata-sections -MMD
# -w flag added to avoid printing a wrong warning http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59396
# This is fixed in gcc 4.8.3 and will be removed as soon as we update the toolchain
compiler.c.elf.flags=-w -Os -Wl,--gc-sections
compiler.c.elf.cmd=avr-gcc
compiler.S.flags=-c -g -x assembler-with-cpp
compiler.cpp.cmd=avr-g++
compiler.cpp.flags=-c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -MMD
compiler.ar.cmd=avr-ar
compiler.ar.flags=rcs
compiler.objcopy.cmd=avr-objcopy
compiler.objcopy.eep.flags=-O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0
compiler.elf2hex.flags=-O ihex -R .eeprom
compiler.elf2hex.cmd=avr-objcopy
compiler.ldflags=
compiler.size.cmd=avr-size
# This can be overriden in boards.txt
build.extra_flags=
# These can be overridden in platform.local.txt
compiler.c.extra_flags=
compiler.c.elf.extra_flags=
compiler.S.extra_flags=
compiler.cpp.extra_flags=
compiler.ar.extra_flags=
compiler.objcopy.eep.extra_flags=
compiler.elf2hex.extra_flags=
# AVR compile patterns
# --------------------
## Compile c files
recipe.c.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.c.flags} -mmcu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.c.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"
## Compile c++ files
recipe.cpp.o.pattern="{compiler.path}{compiler.cpp.cmd}" {compiler.cpp.flags} -mmcu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.cpp.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"
## Compile S files
recipe.S.o.pattern="{compiler.path}{compiler.c.cmd}" {compiler.S.flags} -mmcu={build.mcu} -DF_CPU={build.f_cpu} -DARDUINO={runtime.ide.version} -DARDUINO_{build.board} -DARDUINO_ARCH_{build.arch} {compiler.S.extra_flags} {build.extra_flags} {includes} "{source_file}" -o "{object_file}"
## Create archives
recipe.ar.pattern="{compiler.path}{compiler.ar.cmd}" {compiler.ar.flags} {compiler.ar.extra_flags} "{build.path}/{archive_file}" "{object_file}"
## Combine gc-sections, archives, and objects
recipe.c.combine.pattern="{compiler.path}{compiler.c.elf.cmd}" {compiler.c.elf.flags} -mmcu={build.mcu} {compiler.c.elf.extra_flags} -o "{build.path}/{build.project_name}.elf" {object_files} "{build.path}/{archive_file}" "-L{build.path}" -lm
## Create eeprom
recipe.objcopy.eep.pattern="{compiler.path}{compiler.objcopy.cmd}" {compiler.objcopy.eep.flags} {compiler.objcopy.eep.extra_flags} "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.eep"
## Create hex
recipe.objcopy.hex.pattern="{compiler.path}{compiler.elf2hex.cmd}" {compiler.elf2hex.flags} {compiler.elf2hex.extra_flags} "{build.path}/{build.project_name}.elf" "{build.path}/{build.project_name}.hex"
## Compute size
recipe.size.pattern="{compiler.path}{compiler.size.cmd}" -A "{build.path}/{build.project_name}.elf"
recipe.size.regex=^(?:\.text|\.data|\.bootloader)\s+([0-9]+).*
recipe.size.regex.data=^(?:\.data|\.bss|\.noinit)\s+([0-9]+).*
recipe.size.regex.eeprom=^(?:\.eeprom)\s+([0-9]+).*
# AVR Uploader/Programmers tools
# ------------------------------
tools.avrdude.path={runtime.tools.avrdude.path}
tools.avrdude.cmd.path={path}/bin/avrdude
tools.avrdude.config.path={runtime.platform.path}/avrdude.conf
tools.avrdude.upload.params.verbose=-v
tools.avrdude.upload.params.quiet=-q -q
tools.avrdude.upload.pattern="{cmd.path}" "-C{config.path}" {upload.verbose} -p{build.mcu} -c{upload.protocol} -P{serial.port} -b{upload.speed} -D "-Uflash:w:{build.path}/{build.project_name}.hex:i"
tools.avrdude.program.params.verbose=-v
tools.avrdude.program.params.quiet=-q -q
tools.avrdude.program.pattern="{cmd.path}" "-C{config.path}" {program.verbose} -p{build.mcu} -c{protocol} {program.extra_params} "-Uflash:w:{build.path}/{build.project_name}.hex:i"
tools.avrdude.erase.params.verbose=-v
tools.avrdude.erase.params.quiet=-q -q
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
tools.avrdude.bootloader.params.verbose=-v
tools.avrdude.bootloader.params.quiet=-q -q
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
# USB Default Flags
# Default blank usb manufacturer will be filled it at compile time
# - from numeric vendor ID, set to Unknown otherwise
build.usb_manufacturer=
build.usb_flags=-DUSB_VID={build.vid} -DUSB_PID={build.pid} '-DUSB_MANUFACTURER={build.usb_manufacturer}' '-DUSB_PRODUCT={build.usb_product}'
The sketch upload is still ok (so far), but no way will the internal frequency change work. I have to unplug the USBasp between uploads, otherwise the next upload will fail - is that to be expected?
I'm getting confused, or the problem makes even less sense than I thought.
Which error are you getting when you bootload, with verbose upload enabled?
What verbose output do you get when you program a sketch over ISP?
I've seen behavior where you need to unplug the programmer after programming to make it work again - this typically indicates that the programmer is continuing to hold reset low (the same behavior can be reproduced by grounding reset while programming it, and not releasing it).
As for the board-manager issue, I think that's a problem with board manager in general? That isn't my json file it's failing to access - maybe it's failing to access one of the built-in ones, and giving up? (implying that right now board manager isn't working for anyone)
