Eliminating the startup delay.

[adrianjgh]

I seem to be going round in circles and not getting anywhere. I'm trying to load a Digispark clone with a program which I would like to start straight away, but what ever bootloader I use, there's always a delay at power on before the program starts.

I don't know whether I'm doing something wrong or the wiring I have is affecting the boot behaviour.

I have a pulse stream coming in from an RC receiver on PB0, PB1 will be a controlled by the program but is currently not connected, PB2 and PB3 go to the anodes of a bicolour LED through 500R resistors, with the cathode taken to GND.

There is a 12K resistor between PB5 and +5V, which is supplied from the receiver.

I've downloaded I don't know how many different bootloaders and none of them have skipped on power up. I'm currently using "upgrade-t85_entry_on_reset_activePullup_fastExit.hex" and changed boards.txt to point to this. I know it's picking up the correct bootloader, because it throws an error on uploading if I remove the first colon from the file.

If I take the reset pin low, the bootloader loads as expected, but none of the bootloaders I have tried will skip the bootloader at power up. And PB3 goes high whilst the bootloader is active. The USB is only connected when I'm uploading, and not when plugged into the receiver.

Currently using ATTinyCore 1.5.2 and Arduino IDE version 2.2.1, which appears to be working and certainly updates my program OK, so I've assumed it will be loading the bootloader correctly as well.

[SpenceKonde]

The codebase that was used for 1.5.2 has changed dramatically for 2.0.0, please retest with the bootloader files in the head of this repo.

You need to have something about the reset that causes it to load the bootloader, and under that situation, there will be a delay. Otherwise there would be no way to upload to it. This is either the reset flags (PORF, EXTRF, WDRF (I don't know if that works), on any reset, or an even more permissive "always" option, or a "Jumper" option that runs the bootloader only if a certain pin is grounded. Extrfonly_safe does it on external resets only - unless it sees a 1 on the reset pin, which indicates that reset must be set as GPIO, and the pin is high. And in that case it will run on POR so you can upload the bootloader upgrade file for a more appropriate version without having to HVSP the part to make reset back into reset to program an appropriate bootloader and fuses

Of course, if you use an ISP programmer instead of the VUSB bootloader, there will never be a bootloader delay.