ATTiny85 won't boot if PIN2 is not pulled high

Question

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);
    delay(250);
    digitalWrite(1, LOW);
    delay(250);
  } else {
    digitalWrite(1, HIGH);
    delay(1000);
    digitalWrite(1, LOW);
    delay(1000);
  }
}

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.

Answer 1

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:

:0119FA00XXSS

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.

Answer 2

I had the same problem, I changed to firmware micronucleus-1.11-upgrade.hex (from 2.3 to 1.11) and it was solved, you can find ir here https://github.com/micronucleus/micronucleus/tree/v1.11/upgrade/releases