ATtiny 841 Programming Error (Device Signature)

If you do upload with the optiboot board def selected, it tries to upload using the bootloader, so its talking to the bootloader on the arduino uno you were using as isp (which reports that its a 328p, causing avrdude to stop the process).

If you want to use the bootloader, connect a serial adapter as described in the attinycore docs.

If you dont want to use a bootloader, and want to just upload via isp, select the (no bootloader) version. (You do still have to do burn bootloader to set the fuses - this is the standard arduino behavior)

Btw - are you still using the ATtiny Modern core, instead of the unified ATtinyCore? I combined them ages ago and have been adding new features and fixes to the combined version only, see link in my sig or github. The biggest feature is probably the unified wire/spi libraries - you can now just use Wire.h and SPI.h and unmodified libraries for i2c/spi devices - you dont need special versions and libraries adapted for ATtiny parts. Everything is automagically handled for you by the special version of those libraries included with the core. Export compiled binary also outputs assembler listings now too.

I'll see if that works. As for ATtinyCore, I'm using a school laptop and they blocked GitHub so I had to try to find a way around it by downloading the core from home. I think they just unblocked it on the computer's we filter but it's still blocked on the routers at school. When installing it, should I delete the old cores first or leave them and install the new one?

edit It turns out that I did have the ATtinyCore installed and I was able to link it with the URL instead of manually installing it. I decided to delete both libraries and make sure the core was updated through the boards manager. Thanks for your help, I'll see if choosing no optiboot works on Monday because all of my equipment at school. I only have an ICSP header on the pcb so I can't use a serial interface.

If you have manually installed the core, you should delete it before installing via board manager (or manually installing the latest version). That said, the version you get by downloading from github and manually installing is usually a few updates ahead of the one you get from board manager - see https://github.com/SpenceKonde/ATTinyCore/blob/master/ChangesNotInBoardManagerYet.md

The school... which is trying to teach computer related things... has blocked github? I'm just speechless.

I know right, all I needed was access over ethernet to connect a raspberry pi running octoprint for a school 3D printer and now it can't automatically update... at least they forced me to learn how to bypass securities...

Ok, new error... maybe because it isn't the most up to date? It has optiboot burned onto it and then I used the ATtiny841 (no optiboot).

avrdude: Version 6.3, compiled on Jan 17 2017 at 12:00:53
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "C:\arduino-1.8.5\portable\packages\arduino\tools\avrdude\6.3.0-arduino9/etc/avrdude.conf"

avrdude: AVR Part "attiny841" not found.

Then it says a bunch of valid parts... and ends with this:

  ucr2     = deprecated, use 'uc3a0512' [C:\arduino-1.8.5\portable\packages\arduino\tools\avrdude\6.3.0-arduino9/etc/avrdude.conf:14615]

edit
I'm not too sure that it's because I used the board manager because there wasn't anything listed in the changes not yet in the board manager that would indicate it's missing. I search the avrdude config file and there's no mention of the ATtiny841... I even tried installing the core manually (cellular hotspot to bypass the web filter :wink: )

edit 2
I thought that maybe because I have a portable version of Arduino IDE (I didn't have admin access when I installed arduino... I've since found a way around that but haven't needed to change Arduino so I left it) that the core was in the wrong location so I made a copy and put it in the C:\arduino-1.8.5\portable\packages folder but that didn't change anything.

Use the programmer option that has the (ATTinyCore) after the name - there's a longstanding "feature" of the IDE that causes it to ignore the directives of a custom hardware package's platform.txt that direct the IDE to use the avrdude.conf file that the custom hardware package supplies when uploading sketches to the board when using an ISP programmer, if the selected programmer was not supplied by a custom hardware package. So it uses the default avrdude.conf which doesn't contain definitions for a large number of parts. ATTinyCore supplies a duplicate of the programmer definitions to work around this stupid behavior, these are named with (ATTinyCore) after the name of the programmer.

Ok, everything works now except I am suddenly receiving an error when compiling for upload...

avr-gcc: error: C:\Users\1006602\AppData\Local\Temp\arduino_build_521022/..\arduino_cache_581922\core\core_ATTinyCore-master_avr_attinyx41_chip_841,LTO_disable,clock_16external,eesave_aenable,bod_1v8,bodact_disabled,bodpd_disabled,pinmapping_anew,wiremode_amaster_b38033a7b4a180433b55889669b5e250.a: No such file or directory

exit status 1
Error compiling for board ATtiny441/841 (No bootloader).

It happens on every sketch I try including new ones... I'm not sure why because it didn't used to do this.

edit
I read your read-me document in the downloaded core, really useful stuff... probably should have read that before :sweat_smile: . I'll downgrade my board version to 1.6.21 and see what happens.

edit 2
Nope, same error...

Do sketches for standard AVR-based Arduino boards compile successfully? That looks like the core.a file not found error, but that typically effects all boards, whether or not from a custom core (and is related, IIRC, to an overly-aggressive antivirus program interfering with the compilation process).

Yeah, normal sketches compile and I'm able to upload them to other microcontrollers. The error only comes when attempting to upload to the 841. I'll try it on a home computer to see if it's something with the school's settings.

When I was setting up a 32u4 for the same project, it was weird because it wouldn't let me burn the Pro Micro bootloader but it would let me burn the Leonardo bootloader. Once that was there, it then let me burn the Pro Micro bootloader...

SUCCESS!

So after literally a month of research and testing, I figured out that even though the original method described above wasn't working due to some mysterious error... I was able to keep the '841 w/ optiboot' selected and use the hotkey CTRL+SHIFT+U for uploading with a programmer in order to successfully upload a sketch. I didn't want to use an FTDI programmer because it is slower and I didn't have one on hand (plus all of my designs were based on the use of the ICSP header). Both methods of uploading a sketch are supposed to bypass the arduino as an ISP so that the computer thinks its talking directly to the ATtiny841 but obviously selecting w/o optiboot didn't want to work. Plus this is an easier method to. Thanks for your help on with this DrAzzy even though half my questions were literally in your "ReadMe" document :sweat_smile: .

Ccope19:
SUCCESS!

So after literally a month of research and testing, I figured out that even though the original method described above wasn't working due to some mysterious error... I was able to keep the '841 w/ optiboot' selected and use the hotkey CTRL+SHIFT+U for uploading with a programmer in order to successfully upload a sketch. I didn't want to use an FTDI programmer because it is slower and I didn't have one on hand (plus all of my designs were based on the use of the ICSP header). Both methods of uploading a sketch are supposed to bypass the arduino as an ISP so that the computer thinks its talking directly to the ATtiny841 but obviously selecting w/o optiboot didn't want to work. Plus this is an easier method to. Thanks for your help on with this DrAzzy even though half my questions were literally in your "ReadMe" document :sweat_smile: .

You really shouldn't have to do that.

So with everything the same as your working setup, but ATtiny841 (no bootloader) selected, upload gives the part not found error still?
What programmer option are you using? Is it one with (ATTinyCore) after the name?

Try using Upload Using Programmer with ATtiny841 (no bootloader) selected?

DrAzzy:
You really shouldn't have to do that.

So with everything the same as your working setup, but ATtiny841 (no bootloader) selected, upload gives the part not found error still?
What programmer option are you using? Is it one with (ATTinyCore) after the name?

Try using Upload Using Programmer with ATtiny841 (no bootloader) selected?

ATTinyCore is selected for the board(s) and programmer and I am using "Arduino as ISP (ATTinyCore)" These are the results after some testing with chip selection and upload method:

  • Optiboot & Normal: Fail (Fuses, expected)
  • Optiboot & Programmer: Functions
  • No Bootloader & Normal: Fail (Missing file, unexpected)
  • No Bootloader & Programmer: Fail (Missing file, unexpected)

This is the test code I used to see if it would upload:

/*
 * Keyboard Test 2.1
 * 4/5/19
 * Created by Ccope19
 */
 
void setup() {
  // pins go to buttons which are connected to GND
  pinMode(4, OUTPUT);           // SDA Output
}

void loop() {
  digitalWrite(4, LOW);
  delay(250);
  digitalWrite(4, HIGH);
  delay(250);
}

I'm able to write to digital pins but I'm having trouble using the digitalRead command. I have buttons that connect to GND and the internal pullup resistor. I've verified that all of my solder joints are good and my mechanical key switches function as well as verifying the code on a Pro Micro and Uno. Is there something that's is different for the '841?

void setup() {
  // put your setup code here, to run once:
  pinMode(10,INPUT_PULLUP);
  pinMode(4, OUTPUT);
}

void loop() {
  // put your main code here, to run repeatedly:
  int a = digitalRead(10);
  if (a == HIGH){
    digitalWrite(4, LOW);
  }
  else {
    digitalWrite(4, HIGH);
  }
}

I have tested the I2C communication with the SlaveRecieve/MasterWrite code under the Wire reference. I'm using both Master and Slave on the '841 because it will be communicating back and forth with a 32u4.

Are you using the pin mapping you think youre using? There is a clockwise and counterclockwise configuration option. Make sure you are using the correct one for the pin numbers you're using.

It is expected that with Arduino as ISP (without the ATTinyCore after it) it will fail.

Wait - when you are trying to upload to a board using optiboot, have you connected a serial adapter to the ATTiny and selected the corresponding COM port? That's how you're supposed to do normal sketch uploads with optiboot - it looks like you're still talking to the Arduino that you had used as an ISP.

I will see if I can reproduce your problem with non-optiboot board def.

Actually I'm not sure for pin mapping, my tests with digital 4 and I2C worked right. I'm using a pinout like this (with physical pin 1 being the top left, marked by a dot on the chip):

VCC -1 14- GND
XTAL1 -2 13- D10/A0/AREF
XTAL2 -3 12- D9/A1/TX0
Reset -4 11- D8/A2/RX0
D2 -5 10- D7A3
D3/A7/SS -6 9- D6/A4/SCL/SCK
SDA/MOSI -7 8- D5/A5/MISO

My pin mapping is set to clockwise because counterclockwise says for the old ATTinyCore. I'm selecting the COM port that the UNO is connected to and using the UNO as an ISP. I select the ATTinyCore version of the programmer and select Optiboot for the '841. I have a 16MHz crystal onboard and have both wire modes selected. All of the B.O.D., LTO, EEPROM, and UART setting are whatever are default (typically disabled) because I don't fully know what each one does, mainly the B.O.D. and LTO settings.

D2, D3, D7, D8, D9, & D10 are all supposed to be set as INPUT_PULLUP for the buttons and then my only output is an I2C header. The only other connection is the ICSP header for programming.

Counterclockwise is the pinout you described, see the pinout chart in the documentation. And as you can see you have pins numbered in counterclockwise order.

Wire.h configures the pins used regardless of which pin mapping is selected (and manages pin modes for them as it needs to change the pin mode during operation.)

I just tried to reproduce your issues with the non-optiboot board definition.

Using a USBAsp (ATTinyCore), I was able to burn bootloader and upload sketches without issue.

Can you please include the full text of the error message you get when trying to use the non-optiboot version? I'm trying to figure out if there's a problem with my core, or some issue with your configuration. I tested in 1.8.9 and 1.8.5 and could not reproduce it in either of them. Clearly there is something different about our configurations, but it's critical to find out whether the key difference is a problem with your configuration, or a problem with my core that only manifests with your configuration.

Also tested in portable mode 1.8.5

It is not expected for any burn bootloader or upload using programmer operations to work with the non-(ATTinyCore) programmer options selected; that's WHY I include a separate copy of all the stupid programmers.

Background: I consider it a bug that the Arduino IDE ignores platform.txt when using a programmer defined in the official board package (especially since it otherwise does not ignore platform.txt). But apparently there are other people who are depending on this behavior, and the Arduino team seems to think this perverse behavior is correct - and so duplicate programmers (these are EXACT COPIES of the entries from programmers.txt in the official core - they just have to be defined by my core, not the official core, otherwise it will ignore the platform.txt line that points to the avrdude.conf that I supply which has all the necessary entries.

Ok, so the pin mapping fixed the problem of reading the digital pins. I'm assuming because I was using D4 (aka SDA) as my output for checking if I could use digitalWrite, I didn't realize the mistake because the Wire library automatically configures the pin output. It also fixed normal uploading with "no bootloader" selected. The only two non-working combinations are the "Optiboot" & normal upload (expected) and then selecting "No Bootloader" and uploading using programmer. That gives me this error:

avr-gcc: error: C:\Users\1006602\AppData\Local\Temp\arduino_build_271608/..\arduino_cache_81214\core\core_ATTinyCore-master_avr_attinyx41_chip_841,LTO_enable,clock_16external,eesave_aenable,bod_1v8,bodact_disabled,bodpd_disabled,pinmapping_old,wiremode_both_b38033a7b4a180433b55889669b5e250.a: No such file or directory

exit status 1
Error compiling for board ATtiny441/841 (No bootloader).
Arduino: 1.8.5 (Windows 10), Board: "ATtiny441/841 (No bootloader), ATtiny841, Enabled, 16 MHz (external), EEPROM retained, B.O.D. Enabled (1.8v), B.O.D. Disabled, B.O.D. Disabled, Counterclockwise (like old ATTinyCore and Rev. C boards), Both (uses more flash)"

avr-gcc: error: C:\Users\1006602\AppData\Local\Temp\arduino_build_271608/..\arduino_cache_81214\core\core_ATTinyCore-master_avr_attinyx41_chip_841,LTO_enable,clock_16external,eesave_aenable,bod_1v8,bodact_disabled,bodpd_disabled,pinmapping_old,wiremode_both_b38033a7b4a180433b55889669b5e250.a: No such file or directory

exit status 1
Error compiling for board ATtiny441/841 (No bootloader).

This report would have more information with
"Show verbose output during compilation"
option enabled in File -> Preferences.

Everything works now when I use either the "No Bootloader" version with a normal upload or the "Optiboot" version with the "Upload using programmer" option. If you want I can safe a .zip file of my system arduino folder because it's a portable version and I can PM you the link in a Google Drive.

I have reproduced the error. It is not linked to the settings you have said (nor is it linked to uploading at all!)

I can reproduce it on Arduino 1.8.5 in portable mode by simply compiling bare minimum for attiny841 twice. The first compile succeeds, the second one fails. The problem is related to core caching, and how 1.8.5 names the cached core file - it concatenates all the board options in the file name, resulting in a name that exceeds the windows MAX_PATH length.

And changing the board selection fixes it for one build (build options changed, rebuilding all).

It does not occur in Arduino 1.8.9 which uses a different naming scheme for the cached core file.

I will change the internal names for the options in ATTinyCore 1.2.4

On some versions of Arduino IDE, cached cores exceed MAX_PATH on windows · Issue #313 · SpenceKonde/ATTinyCore · GitHub will be in next release

Thanks for reporting this issue.

I may end up backing this change out of the core and stating that those versions of the IDE are unsupported - it turns out to cause breakage for people automating the build process.

Change has been reverted until I can figure out what to do about this.