I had some problem setting up a working ATTiny85 outside of its development board.
Connection on my breadboard:

pulled high (10K R)  -- 1  PIN 8  -- VCC (+5V)
     trouble here!!  -- 2  PIN 7  --
                     -- 3  PIN 6  -- LED
               GND   -- 4  PIN 5  --

as you can guess pins are referred to actual chip's pins enumeration.
My simple test code:

void setup() {
  pinMode(1, OUTPUT);
void loop() {
  if (analogRead(A1) > 512) {
    digitalWrite(1, HIGH);
    digitalWrite(1, LOW);
  } else {
    digitalWrite(1, HIGH);
    digitalWrite(1, LOW);

I'm using Arduino IDE v1.8.13 with digistump avrboards v1.6.7.

I flashed t85_default micronucleus v2.5 bootloader in my chip with fuses set to lfuse:0xe1, hfuse:0xdd, efuse:0xfe.
The problem is that if I power the chip with PIN2 not pulled high it won't start execution of the code, it won't blink. If it’s started from pulled high, it will start code about 5s after power on. If it’s started pulled low code won’t execute until is pulled high. As I pull high, even just for a second, PIN2 it will start blinking and executing code.

Is it normal? I think I have missed something.


Well, I've made some headway. I hope to update this with something more helpful though.

I don't have a digispark or even the correct Zener diodes to replicate the necessary parts of it. However, I did install t85_default.hex on an ATTiny85 with some alterations to the hex file to place break instructions in a few strategic places. And then I ran avarice/debugwire against it.

The basic problem is that it's trying to tune the internal oscillator against the USB frames by looking at the D- pin. Basically, it's stuck in tuneOsccal.

988  00001d06 <tuneOsccal>:
   1     1d06:       b3 9b           sbis    0x16, 3 ; 22
   2     1d08:       fe cf           rjmp    .-4             ; 0x1d06 <tuneOsccal>
   3     1d0a:       07 d0           rcall   .+14            ; 0x1d1a <countFrame>

So if you want to avoid this, you need to compile with that feature off, and there is a feature to do that.

I have not yet run one with this feature disabled. But I did compile t85_default once, using make CONFIG=t85_default and found it necessary to remove the START_WITHOUT_PULLUP from the first line of the t85_default/bootloaderconfig.h file.

The code mentions the existence of OSCCAL_SAVE_CALIB, which lets you specify your own OSCCAL value, assuming the factory one for the chip isn't good enough for whatever reason. But there doesn't seem to be any guidance on how you're supposed store it or where. Looking at the code though, if enabled, you can see it loads the OSCCAL value from just before where the bootloader starts.

A simple way to put it there without messing with command-lines and linker scripts would be to just edit the the t85_default.hex that results from building with OSCCAL_SAVE_CALIB enabled, and add an extra record for setting the osccal value at the correct address, which I guess would be 0x19FA, so:


Where XX is whatever you've determined your OSCCAL value is and SS is the checksum value, or 0x100 - ((0x14 + XX) & 0xFF) in this case. Or, if you want to be lazy, put whatever you want for SS and let AVRDude complain tell you what it's supposed to be when it tries to load the .hex file. It will report the expected value in decimal, which you can convert to hex and patch into the file, and run AVRDude again.

  • Wow, this is very complicated for my level of understanding, but thanks to references you put in the answer I got the point. It would be kind of difficult for me to edit code given that I don't know assembly and I have a superficial knowledge of c++. For now I think I just start it with pin2 pulled high, then I will try to patch the hex file as you suggested. BTW I think you did a great job with this answer. Thank you. Mar 24 at 8:23
  • 1
    I will look into making some short instructions. You won't need to know assembly at all. The first step would be to just use the standard osccal calibrations and see if that does the job, which wouldn't involve editing the hex file at all. I may try to get set up to actually attach to USB, which may take quite a while. Longer than you might think.
    – timemage
    Mar 24 at 12:50
  • 1
    @ZenoDallaValle, I have what amounts to a digispark clone (or rather kit) coming that uses a socketed ATTiny85. When I get it (which may be a while) and assemble it, I'll see about updating the answer with the process used.
    – timemage
    Mar 25 at 15:25

Your Answer

