1
\$\begingroup\$

I wanted to port a simple program from an Attiny85 to the cheaper Attiny13. To make sure everything would work properly I started trying to upload a simple blink program to the MCU but could not get the USBtiny to communicate with the MCU, I would always get the initialization failed, rc=-1 message.

Since my issue was with establishing connection with the MCU I ditched the hex file and just ran avrdude -c usbtiny -p t13. I had everything set up so that I could just switch an Attiny85 for the Attiny13 since their pinouts are identical. The tiny85 worked exactly as expected, having no issues answering back and being programmed.

Researching online I tried the -B option for AVRdude with different values thinking it could have something to to with the clock speed, but always got the same initialization error.

After messing around some time I decided to probe the serial lines with an oscilloscope, and to my surprise I found that when running the avrdude command with the Attiny13 in place, the logic levels became really weird, having a high voltage of 5V and low voltage of approximately 4V instead of 0V. Under the EXACT same conditions tha Attiny85 didn't yield these strange voltages. You can check the scope trace images, first one is with the Attiny85 and the second with the Attiny13.

Attiny85 normal behaviour Attiny13 with abnormal logic levels

My set up/toolchain consists of a fresh WinAVR install and Sparkfun Pocket AVR programmer (USBtinyISP). Both the Attiny13 and Attiny85 are new from the same supplier, in SOIC packages so I'm using them on a breakout board. Tried a second Attiny13 chip but results were the same.

\$\endgroup\$
6
  • 1
    \$\begingroup\$ Sounds like the target chip is still fighting to do its own thing because you are not entering ISP mode, either because you are not making all of the necessary connections or because the chips in question have been fused in a way that disables ISP and/or reset. Or they might not even be ATtiny's at all, but something fraudulently mislabeled. But double check the connections first, and make sure they are new, unused parts from a reputable source and not a random internet bargain site. \$\endgroup\$
    – Chris Stratton
    Jun 28, 2020 at 4:08
  • \$\begingroup\$ Or they could be fused for external clock and you are not providing one... Critically missing here is a schematic of your setup, and affirmation of the genuine, unused nature of the parts. \$\endgroup\$
    – Chris Stratton
    Jun 28, 2020 at 4:17
  • \$\begingroup\$ Wiring certainly isn't the problem. The circuit consists of the 3 serial lines + reset + power going from the USBtiny to the breadboard. Also, as I said, when switching between Attinys on the breadboard (lifting one and dropping the other one) the Attiny85 worked perfectly. Only way wiring is an issue is if the Attiny13s I have are fake. This would be strange since the seller is very reputable and I never had any problems with their other AVR chips (ATmega328P, 328PB, 48 and Attiny85) \$\endgroup\$
    – jjpprr
    Jun 28, 2020 at 12:27
  • \$\begingroup\$ As for the clock issue I'll try to play around with that. I didn't bother because the datasheet states that by default they are set to use the internal oscillator, and also I fail to see how missing the clock signal would have any effect on the logic levels. \$\endgroup\$
    – jjpprr
    Jun 28, 2020 at 12:29
  • \$\begingroup\$ Hmm, maybe I'm reading the wrong datasheet, but I downloaded them directly from Microchips site. Save for differences in pin functions I can't see how the pinout are different. More importantly, the ISP and power functions are the same on both chips: RESET on pin 1, MOSI on pin 5, MISO on pin 6 and SCK on pin 7. \$\endgroup\$
    – jjpprr
    Jun 28, 2020 at 15:26

1 Answer 1

Reset to default
2
\$\begingroup\$

Well, after around 6 or 7 hours of dealing with this I finally solved it when I started playing around with a high voltage programmer. I hope this can help someone in the future.

The problem was that the Attiny13 came with the fuse bits set wrong. They were F6 F8, which meant that ISP programming was disabled (SPIEN bit unprogrammed). To make matters worse the lock bits seem to have been set, preventing me from writing the correct fuse values, even with the high voltage programmer.

Luckily I stumbled online with someone who had the same issue and mentioned having to perform a chip erase (which clears the lock bits but doesn't affect the fuse bytes) and only after that write the fuse values.

The resources which helped me were the following:

Thread with similar issue on arduino forum

High voltage programmer schematic (To be honest I didn't use the transistor and ditched all resistors save for the one from the 12V supply to the reset pin)

Post explaining this very same issue

Arduino code from said post (I recommend reading the post, but the TLDR is uncomment the chip erase lines of code to deal with the lock bits issue)

\$\endgroup\$
2
  • 3
    \$\begingroup\$ As pointed out in comments where this possibility of the reset disable fuse was raised, this means you received used or previously programmed parts, it would seem your seller is not as "very reputable" as believed. \$\endgroup\$
    – Chris Stratton
    Jun 30, 2020 at 2:37
  • \$\begingroup\$ It certainly seems so which is a shame. Nothing remotely close to digikey or mouser where I'm from so I will have to make do. \$\endgroup\$
    – jjpprr
    Jun 30, 2020 at 12:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.