Because I am stoopid, if you used a -jumper version of micronucleus, update now!

[DeuxVis]

Fine, and here's the link to that wiki section : http://digistump.com/wiki/digispark/tricks?s%5B%5D=micronucleus#get_rid_of_5_second_startup_delay

[zapta]

Let's said that I programed a DS with my program using the stock bootloader (the one with 5 secs delay) and then I program the board with this  'jumper' bootloader, do I need to reprogram the board with my program? 

Thanks,

Z.

[DeuxVis]

From memory, I think yes you need to upload your program again.

But don't take my word on this, try it, reuploading a sketch is just some seconds away anyway (unless you lost your sources).

[Bluebie]

Yes you absolutely will need to upload your program again, and there is no way to recover the code for a program you've already uploaded. Well.. maybe a high voltage serial programmer could do it? Depends how @digistump set the fuses in the spark.

[zapta]

Thanks Bluebie.

In a related question, let's say that I have the .hex file of the jumper bootloader and .hex file of my application.  Is there a way to combine then such that people can:

1. Program both of them into a stock Digispark.

2. Not having to deal with the jumper (I care only about the first time they programming it).

(Motivation, I have an Digispark application that requires no 5 seconds delay. I want to make it easy for laymem to program it (once) on boards they order from Digistump.)

[Bluebie]

Nope. The upgrade hex file uses the same space as your program. It is an installer program. You have to do them in sequence. If you want to do that, currently the only way is to use a high voltage serial programmer. Then you can upload both together, which is infact how digistump load on the bootloader and the blink program when they make them I think!

[zapta]

Thanks Bluebie.

When the loader runs, does it have access to the program's EEPROM space and/or flash? If so, how about have a having a flag in the flash/EEPROM that will tell the boot loader if to use delay or jumper?  This will give us, app programmers, more control with the stock bootloader.

[Bluebie]

That feature would make the bootloader bigger. I don't see why it's worth it when you can swap out the bootloader so easily.

[zapta]

That feature would make the bootloader bigger. I don't see why it's worth it when you can swap out the bootloader so easily.

Yes, swapping the bootloader is easy but than you need to deal with soldering a temporary jumper before you program the application.

[Bluebie]

soldering? why would you solder it? just get a piece of wire and press it in while you plug the usb connector in. In some of my projects instead I also have a button connected from d5 to gnd, which I use in my programs as input to control something, but can also be held down when plugging it in to enter the bootloader. You don't need to keep it connected for the whole upload either, just for the first 20 milliseconds or so, I think!

[zapta]

Thanks Bluebie. 

I am trying to understand the program memory model of the tiny85. Both the bootloader and my program's hex file start at 0000. If they are in the same memory space how do they coexist?

[Bluebie]

It depends which bootloader hex file you use. The regular firmware/releases stuff in the github repository are the already installed images, and they don't start at 0000 - they start somewhere around 6kb in. I believe the hex files sometimes do contain 0000 or ffff padding words up until that point though.

If you're looking at the 'upgrade' stuff, it is an installer. So the regular firmware/releases stuff is read in, the padding bytes at the start are stripped off, and the bootloader program data are stored in to a byte array inside an installer program, which begins at the beginning of memory like any normal program. When the installer runs it first erases it's own interrupt vector table (the first page) making it in to a NOP sled, so if the device restarts it skips the existing bootloader and reruns the installed. Next it writes over the end of the chips program memory with the new bootloader code, then once it's installed it replaces that first page with a trampoline which bounces (jumps) to the start of the bootloader. This renders the installer dead. It then emits a beep if you have a speaker attached or if an LED is attached you see it light up for a moment, then it jumps to 0000 which trampolines in to the bootloader and connects over USB to your computer.

The reason we have the 'upgrade' installer is that you can upload it via another bootloader or via micronucleus itself, so you can use it to upgrade chips without needing to have a programmer of any sort. In the case of the digispark you would need a high voltage serial programmer which tends to cost about $50 if not for the installer program. If you're wondering, I had the idea after crashing a university course on computer security and seeing how worms deliver payloads and unpack over different parts of memory, patching things in to place and rewiring jumps. This is why I sometimes call it the 'viral installer'. In the future I'd like to add checksums and a verification step, but I still consider it very safe in it's current form.