ATtiny85 (Micronucleus / Digispark): no bootloader file selected?

[Erik84750]

In boards.txt under ATtiny45/85 (Optiboot) there is a selection for the relevant bootloader file:
attinyx5opti.bootloader.file=optiboot/optiboot_{build.mcu}_{build.f_cpu}.hex

Why is there no such provision for the Digispark board, for loading the relevant micronucleus file?
All that seems to be done is fuse settings?
Would it not be an advantage also to be able to select a specific micronucleus version?

[SpenceKonde]

Huh, its definitely usipposed to; have a far better verion that the otriinal; I'll be doing mass builds of micronucleus for 2.0.0 or 2.0.1

[Erik84750]

In boards.txt line 440 (ATtiny45/85 (Optiboot) following line is seen:
attinyx5opti.bootloader.file=optiboot/optiboot_{build.mcu}_{build.f_cpu}.hex

This implies loading the optiboot file needed according to mcu en frequency selected I understand.

However under ATtiny85 (Micronucleus / Digispark) no such similar line is found? There is a line 537 that states the upload tool to be micronucleus using usb protocol?
Would it not be an advantage to be able to use avrdude too as an option, to upload a micronucleus bootloader of choice?

[SpenceKonde]

I KNEW it was in there. It's just in a different place because there are two different ways that one can install a bootloader on a Micronucleus board. The ISP programming method is the only one available for everything else.

On micronucleus t is more common to disable to reset pin (micronucleus, unlike optiboot, is actually robust and largely impossible to corrupt without intentionally uploading a sketch that overwrites it - optiboot can fail in such a way that the reset vector (which is rewritten to send execution to the bootloader) has been erased but the rest of the sketch has not. Hence, the code will reach an incompltete application which repeatedly crashes (since the stack pointer hasn't been set up and r1, which the compiler relies on always containing 0, won't contain 0. I looked into fixing this (when asked to erase the first page at the start of an upload, erase every page, starting from highest address and working downwards, and place the application vector in the last word of the last page, so an interrupted erase does not break the bootloader either)and.... it's a surprisingly large amount of work), and we do indeed offer the option to disable the reset pin (which requires exotic HV programming to undo in order to program via ISP ever again).

But not having a reset pin poses a problem.... Micronucleus keeps getting better (less dramatically these days, but in the early days, it was roaring ahead by leaps and bounds, so while early tiny85's with the bootloader used almost half of their flash on the bootloader, the latest one uses only 1.5k (3/16ths of the flash). But if you disabled reset, how could you update the bootloader? If you haven't noticed,

And so what they do is make an "upgrade" hex file that combines the binary for the new bootloader, stored as data, with a small program that redirects the reset vector to itself instead of the bootloader (I think the whole program is located after the first page of flash, so if this fails, execution will still end up at the updater) . Hence, whereas for every other part, simply saying "burn bootloader" is unambiguous: it means "Set the fuses, and upload the bootloader, if there is one." that doesn't make sense for a micronucleus board, because it could mean you wanted to use an ISP programmer to set the fuses and upload the bootloader, or it could mean that your board has an old bootloader that sucks on it, and you want to upgrade it to the latest version. That is what the "burn bootloader mode" tools submenu is for - you can select either using an ISP programmer, which will set fuses and install the bootloader, regardless of what was there, or the upgrade option, which will upload this booltoader-updater via micronucleus (but of course, this can't change fuses) In boards.txt, this is covered like so:

attinyx5micr.menu.burnmode.upgrade=Upgrade (via USB)
attinyx5micr.menu.burnmode.upgrade.bootloader.file=micronucleus/upgrade-t85_entry_on_power_on_no_pullup_fast_exit_on_no_USB.hex
attinyx5micr.menu.burnmode.upgrade.bootloader.tool=micronucleus
attinyx5micr.menu.burnmode.install=Fresh Install (via ISP)
attinyx5micr.menu.burnmode.install.bootloader.file=micronucleus/t85_entry_on_power_on_no_pullup_fast_exit_on_no_USB.hex
attinyx5micr.menu.burnmode.install.bootloader.tool=avrdude

[Erik84750]

If a compiled binary export is selected then this file does contain the micronucleus bootloader.
Hence if burned over ISP (with for example USBtinyISP) using "Fresh install" compilation, the chip flash will contain both a bootloader section and the actual program?

[SpenceKonde]

No. You cannot erase only part of the flash via ISP (this is part of their code protection scheme - otherwise someone could erase just the first page or two, to make room for a super tiny program that read out the proprietary data from a locked chip). ISP programming can only do a "chip erase" (chip erase is also the only thing that clears the lockbits)

Invoking AVRdude manually you could get it you a chip whose flash contained a bootloader and the application, but it might as well not, because the bootloader could never run! The tinyAVR parts do not have hardware bootloader support (there's no BOOTRST fuse to tell it to jump somewhere other than 0x0000 on reset), the bootloaders has to find some "trick" to make sure they run before the application. They do this by modifying the application code during the upload. the reset vector is stashed, and written to a different location (in the case of micronucleus, and any robust bootloader (ie, not optiboot, which is half of it's problem), the final word of the final page in flash before the beginning of the bootloader is written with an rjmp instruction pointed to the same location that the reset vector of the program you uploaded was.

If you upload via micronucleus, then read it via ISP. you'll find that in addition to the bootloader the end, 4 bytes were different. The first 2 are the very first data bytes (in hex files. the first 8 and last 2 hex digits on each line are not part of the data - you can look up the format if you care for more details) would be xxCX (where x is any hex digit, and X is a hex digit larger than 8, back of the envelope calculations suggest that on most parts with latest bootloader versions, it's a A, B, or C - rearrange to CXxx (hex files are in the order that they're stored, and AVR is little-endian. Humans are big-endian, so you swap the bytes to get them in the sensible order) and drop the most significant nybble, convert to decimal, and subtract 2048, and then subtract the result from 2048, and that's the length of the bootloader (in words)+1. At the start of the bootloader, (where the 0xFF's between end of app and start of bootloader end. is the other one: It will be of the form xxCx - the digit following the C is in fact less than 8. Swap them, drop the C and convert to decimal (no subtraction here) - you'll get a number larger than the first one, but not by all that much. Subtract the original number from this. Finally, do the same thing to the first two databytes of the clean application hex file (which will also be xxCx), with the same value as the what you got when you subtracted the number pulled from the start of the bootloader from the number at the start of the hex from the bootloaded board They'll be either the same, or off by 1 (for the reason below).
Cxxx is an RJMP instruction - one of the iirc 10 instructions that each take uop 1/16th of possible 16-bit opcodes) - Relative Jump and the other 12 bits are how far to jump (in words, not bytes). The 12 bits are signed so 000-7FF are forward, 800-FFF are backward (negative). And the count starts from the word following the jmp, (hence, an 00C0 is an rjmp to the next instruction. Very common trick to use when writing assembly, when you need a very very short delay and are short on flash. the nop ("No Operation") instruction, 0000 takes 1 clock cycle to execute, so you'd need 2, rjmp takes 2, even if it's not going anywhere (the simplest timing loop takes 3 words for a delay of a multiple of 3 cycles and 4 words if it's not, and there's a trick for 8 clock delay in 3 words - so any delay that is a multiple of 3 clocks and less than 3x256=768 clocks, plus anything less than 9 clocks, can be done for 3 words or less, and everything else below 768 in 4) FFCF on the other hand will jump back to the current instruction - an infinite loop. Every program compiled by avrgcc has that somewhere, and if you override main() and return from it, that's where you eventually end up.

Aaaaanyway
It's gonna be better in terms of micronucleus choices in 2.0.0 - I'm planning to build it for every chip that it's sane to do so for meaning support for 1634 and 861) - with option to select which entry conditions trigger it based on holding a certain pin low during power on, after a WDT reset, after reset button reset, at power on reset, or any combination of those (though I won't let users burn anything with nothing other than reset button or WDT entry conditions if they're also disabling reaset, and I just figured out how to keep the upgrader from bricking parts in that way)

[SpenceKonde]

back in the day a fair amount of effort was devoted to figuring out a robust and reliable way to prevent the IDE from generating those combined bootloader + sketch files.