Programming ATtiny85 Micronucleus bootloader: what about a reset vector?

Development Tools Uploading
1

Hi, folks.

I have a Digispark clone board (with ATtiny85) from Robojax.com, but somehow the flash memory was empty. It should have had the Micronucleus bootloader installed, but I am not sure if it came empty from the vendor or if I did something to accidentally erase the flash before I was able to try to read it. (I think I remember reading somewhere that earlier versions of Micronuceuls had a bug that caused it to erase itself from flash in some circumstances.)

The way that I found it was empty was, I wrote a special sketch for an Arduiono UNO board (ATmega328p) to read the ATtiny85 signature, fuse bytes, lock byte and OSCCAL factory setting, as well as the first 256 bytes and last 2K bytes of the 8K flash memory (all using ISP protocol and writing results out to the serial monitor connected to the UNO). Everything read back as expected (including the fuse settings for the Digispark clone application - 0xFE, 0xDD, 0xE1 - but with reset enabled), EXCEPT that the flash memory was erased (all set to 0xFF) in both the lower 256 and upper 2K bytes.

So, I was able to use "Arduino as ISP" and avrdude.exe to burn the most recent "default" version of Micronucleus into the ATtiny85 (t85_default.hex)

I am not at home at the moment and forget the actual command I used, but it was something like:

avrdude -p attiny85 -b 19200 -P com3 -Cavrdude.conf -c stk500v2 -v -U flash:w:t85_default.hex:i

(I am not certain it was "-c stk500v2" but I think that's what the Arduino IDE normally uses - apparently it is whatever the "ArduinoISP" sketch emulates. Also I may have got the order of the avrdude options wrong, or left something out, but it was something like the above.)

After "burning in" the t85_default.hex Micronucleus code, I then re-ran my "read-only" sketch to see what I now had in memory. The upper 2K (actually, less than that, starting at address 0x1980) were written with the Micronucleus code, but the lower 256 bytes were still blank (i.e. all 0xFF - no reset vector). (Note that the ATtiny85 does not have a special, protected boot area but I think the Micronucleus code is supposed to protect or copy itself, somehow, when writing new "sketches" into flash memory).

The t85_default.hex file's second-to-last record (just before the "End of File Record"), is a "Start Segment Address Record", specifying address 0x1980:

:040000030000198060

According to the Intel hex format specification document, this seems to have some special meaning for whatever programmer used to (still does?) program Intel 8086 or 80186 chips. But I thought that maybe either avrdude.exe, or the ArduinoISP sketch, would interpret it to write a jump to 0x1980 into the reset vector. Apparently this is not the case.

So, how should the ATtiny85 be programmed to correctly start the Micronucleus bootloader? Is there a specific avrdude option or command that says "write a jump to address XXXX into the reset vector"?

In fact, is address 0x1980 the actual entry point address for Micronucleus?

Thanks and best regards,
DuinoSoar.

2

Yes, this is fine. 0xFFFF is a NOOP instruction, so the processor skates along the NOOPs until it hits the bootloader, and then runs it.

Once you upload a sketch via the bootloader, it rewrites the vector table of the sketch and points reset vector at the bootloader, then jumps to the sketch (I think it achieves this by taking over a rarely used vector, and putting the sketch's reset vector there - that's what optiboot's virtual boot does at least; I imagine microneucleus has to do the same thing or something similar).