Code Monkey home page Code Monkey logo

micronucleus-firmware's Introduction

Micronucleus USB Bootloader for ATtinies / Digisparks

Fork for the firmware / digispark part of the micronucleus repository.

Badge License: GPLv3     Badge Version     Badge Commits since latest     Badge Hit Counter

Stand With Ukraine

If you find this library useful, please give it a star.

🌎 Google Translate


Micronucleus is a bootloader designed for AVR ATtiny microcontrollers with a minimal usb interface, cross platform libusb-based program upload tool, and a strong emphasis on bootloader compactness. To the authors knowledge this is, by far, the smallest USB bootloader for AVR ATtiny.
The V2.0 release is a complete rewrite of the firmware and offers significant improvements over V1.x.
Due to the many changes, also the upload tool had to be updated. The V2.0 upload tool is backwards compatible to the V1.X tool, though.

Digisparks

Usage

The bootloader allows uploading of new firmware via USB. In its usual configuration it is invoked at device power or on reset and will identify to the host computer. If no communication is initiated by the host machine within a given time (default are 6 seconds), the bootloader will time out and enter the user program, if one is present.
For proper timing, the command line tool should to be started on the host computer before the bootloader is invoked / the board attached.
The bootloader resides in the same memory as the user program, since the ATtiny series does not support a protected bootloader section. Therefore, special care has to be taken not to overwrite the bootloader if the user program uses the self programming features. The bootloader will patch itself into the reset vector of the user program. No other interrupt vectors are changed.
Please invoke the command line tool with "micronucleus -help" for a list of available options.


Driver installation

If the Digispark board is not recognized by Microsoft Windows you must install the appropriate driver.
For Windows you must install the libusb driver before you can program the board. Download it here, open it and run InstallDrivers.exe. Clean Micronucleus devices without uploaded user program will not time out and allow sufficient time for proper driver installation. Linux and OS X do not require custom drivers.


Updated configuration for Digispark boards

The new ATTinyCore by Spence Konde shrinks generated code size by 5 to 15 percent. Just replace the old Digispark board manager URL http://digistump.com/package_digistump_index.json (e.g.in Arduino File > Preferences) by the new http://drazzy.com/package_drazzy.com_index.json and install the latest version.

Update the bootloader to a new version

To update your old, flash consuming bootloader, you have 2 choices.

  1. Use the new Digistump board manager URL (see above), choose a bootloader with Tools > Micronucleus variant and then burn it with Tools > Burn Bootloader.
  2. Run one of the Windows scripts like e.g. the 1_Upgrade-t85_default.cmd. The internal mechanism is described here.

If you want to burn the bootloader to an ATtiny87 or ATtiny167 with avrdude, you must use the avrdude.config file in the windows_exe directory where ATtiny87 and ATtiny167 specifications are added.


Fuse setting

The meaning of fuses can be seen with the Engbedded Atmel AVR Fuse Calculator.
Windows helper scripts for setting fuses can be found here.

The default fuses for a Digispark board are:

  • ATtiny85 Lfuse: 0xE1 - (digispark default) 64 MHZ high speed PLL Clock + Startup 64 ms. CPU clock = 64 MHz / 4 = 16 MHz. CPU clock speed can later be reduced by core or user by using the System Clock Prescaler register.
  • ATtiny85 Hfuse: 0xDD - External Reset pin enabled (Pin5 not usable as I/O) + BOD 2.7 V + Enable Serial Program and Data Downloading.
  • ATtiny85 Efuse: 0xFE - self programming enabled.

BOD enabled requires additional 20 µA in sleep state and therefore may be not desirable for low power battery applications. To disable BOD, use 0xDF as Hfuse.

The default fuses for a Digispark Pro board are:

  • ATtiny167 Lfuse: 0xFF - External crystal osc. Frequency 8-16 MHz + Startup 65 ms. The Pro has a 16 MHz crystal.
  • ATtiny167 Hfuse: 0xDC - External Reset pin enabled + BOD 4.3Volt + Enable Serial Program and Data Downloading.
  • ATtiny167 Efuse: 0xFE - self programming enabled.

Flash the bootloader to a bricked device

This can only be done by means of a High Voltage programmer.

If nothing works...

Try another Cable, try another USB-Port, try another Board, try another Bootloader-variant, try another Computer, try another OS.
In this order.


Configuration overview

If not otherwise noted, the OSCCAL value is calibrated (+/- 1%) after boot for all ATtiny85 configurations

Configuration Free FLASH Boot-
loader size
Non default config flags set
t85_agressive

It works for my Digispark boards without any problems :-)
6778 1362 Do not provide calibrated OSCCAL, if no USB attached, ENABLE_UNSAFE_OPTIMIZATIONS
Relying on calibrated 16MHz internal clock stability, not using the 16.5 MHz USB driver version with integrated PLL. This causes the main memory saving.
t85_default 6650 1514 -
t85_entry_on_powerOn 6586 1550 ENTRY_POWER_ON, LED_MODE=ACTIVE_HIGH
t85_entry_on_powerOn_
fastExit
6586 1572 ENTRY_POWER_ON, FAST_EXIT_NO_USB_MS=300, LED_MODE=ACTIVE_HIGH
t85_entry_on_powerOn_
activePullup_fastExit

recommended configuration
6586 1576 ENTRY_D_MINUS_PULLUP_ACTIVATED_AND_ENTRY_POWER_ON, FAST_EXIT_NO_USB_MS=300, LED_MODE=ACTIVE_HIGH
t85_entry_on_powerOn_
activePullup_fastExit_noLED
6586 1558 ENTRY_D_MINUS_PULLUP_ACTIVATED_AND_ENTRY_POWER_ON, FAST_EXIT_NO_USB_MS=300
t85_entry_on_powerOn_
pullupAt0
6650 1538 ENTRY_POWER_ON, USB_CFG_PULLUP_IOPORTNAME + USB_CFG_PULLUP_BIT
t85_entry_on_reset_
activePullup_fastExit
6586 1576 ENTRY_D_MINUS_PULLUP_ACTIVATED_AND_ENTRY_EXT_RESET, FAST_EXIT_NO_USB_MS=300,
AUTO_EXIT_MS=15000 Bootloader timeout increased to 15 seconds (if connected to USB),
LED_MODE=ACTIVE_HIGH.
t85_fastExit 6586 1554 FAST_EXIT_NO_USB_MS=300, LED_MODE=ACTIVE_HIGH
t88_default 6778 1350 LED_MODE=ACTIVE_HIGH
For 16 MHz quartz
t88_entry_on_powerOn_
activePullup_fastExit

recommended configuration
6778 1394 ENTRY_D_MINUS_PULLUP_ACTIVATED_AND_ENTRY_POWER_ON, FAST_EXIT_NO_USB_MS=300, LED_MODE=ACTIVE_HIGH
For 16 MHz quartz
t167_default 14970 1342 -
t167_entry_on_powerOn_
activePullup_fastExit

recommended configuration
14970 1406 ENTRY_D_MINUS_PULLUP_ACTIVATED_AND_ENTRY_POWER_ON, FAST_EXIT_NO_USB_MS=300, LED_MODE=ACTIVE_HIGH
For 16 MHz quartz
t167_entry_on_reset_
activePullup_fastExit
14970 1406 ENTRY_D_MINUS_PULLUP_ACTIVATED_AND_ENTRY_EXT_RESET, FAST_EXIT_NO_USB_MS=300,
AUTO_EXIT_MS=15000 Bootloader timeout increased to 15 seconds (if connected to USB),
LED_MODE=ACTIVE_HIGH.
For 16 MHz quartz
t45_default 2554 1514
t4313_default 6714 1460
Nanite841 6586 1548
t841_default 6650 1514
t84_default 6650 1480
m168p_extclock 1498
m328p_extclock 1498

Legend

  • ENTRY_POWER_ON - Only enter bootloader on power on, not on reset or brownout.
  • ENTRY_EXT_RESET - Only enter bootloader on reset, not on power up.
  • ENTRY_D_MINUS_PULLUP_ACTIVATED - Only enter if pull-up connected and powered.
  • FAST_EXIT_NO_USB_MS=300 - If not connected to USB (e.g. powered via VIN) the user program starts after 300 ms (+ initial 300 ms) -> 600 ms. If connected to USB but no upload happens the user program starts after around 1.5 seconds.
  • LED_MODE=ACTIVE_HIGH - The built in LED flashes during the 5 seconds of the bootloader waiting for commands.

Descripion of the configuration options

FAST_EXIT_NO_USB_MS for fast bootloader exit

If the bootloader is entered, it requires minimum 300 ms to initialize USB connection (disconnect and reconnect). 100 ms after this 300 ms initialization, the bootloader receives a reset.
The 100 ms time to reset may depend on the type of host CPU etc., so I took 200 ms to be safe to detect a reset.
This configuration waits for 200 ms after initialization for a reset and if no reset detected it exits the bootloader and starts the user program.
With this configuration the user program is started with a 500 ms delay after power up or reset if no USB is attached, even if we do not specify a special entry condition.
IF USB is attached, we wait another 1200 ms (to cover slow hosts, otherwise 500 would be OK) after the reset for the host upload program (micronucleus.exe) to request the configuration information. If no upload program is detected, we start the user program.

ENTRY_POWER_ON entry condition

The ENTRY_POWER_ON configuration adds 18 bytes to the ATtiny85 default configuration.
The content of the MCUSR is copied to the GPIOR0 register to enable the user program to evaluate it and then cleared to prepare for next boot.
In this configuration a reset will immediately start your user program without any delay.

ENTRY_EXT_RESET entry condition

The ATtiny85 has the bug, that it sets the External Reset Flag also on power up. To guarantee a correct behavior for ENTRY_EXT_RESET condition, it is checked if only this flag is set and MCUSR is cleared before start of user program. The latter is done to avoid bricking the device by fogetting to reset the PORF flag in the user program.
For ATtiny167 it is even worse, it sets the External Reset Flag and the Brown-out Reset Flag also on power up.
The content of the MCUSR is copied to the GPIOR0 register before clearing it. This enables the user program to evaluate its original content.
ATTENTION! If the external reset pin is disabled, this entry mode will brick the board!

Activate the bootloader only if the D- pin is high, i.e. a pull-up resistor is attached and powered and we have an ENTRY_POWER_ON condition (ref. described above).
Useful if the pull-up is powered by USB V+ and NOT ATtiny VCC to save power. In this case often a schottky diode is connected between USB V+ and VCC (5V).
The ENTRY_D_MINUS_PULLUP_ACTIVATED_AND_ENTRY_POWER_ON configuration adds 54 bytes to the ATtiny85 default configuration.
The content of the MCUSR is copied to the GPIOR0 register to enable the user program to evaluate it and then cleared to prepare for next boot.
In this configuration a power up with USB disconnected or a reset will immediately start your user program without any delay.

Activate the bootloader only if the D- pin is high, i.e. a pull-up resistor is attached and powered and we have an ENTRY_EXT_RESET condition.
Useful if the pull-up is powered by USB V+ and NOT ATtiny VCC to save power. In this case often a schottky diode is connected between V* and VCC.
The ENTRY_D_MINUS_PULLUP_ACTIVATED_AND_ENTRY_EXT_RESET configuration adds 54 bytes to the ATtiny85 default configuration.
The content of the MCUSR is copied to the GPIOR0 register to enable the user program to evaluate it and then cleared to prepare for next boot.
In this configuration a power up with USB disconnected or a reset will immediately start your user program without any delay.

The bootloader reset vector is written by the host and not by the bootloader itself. In case of an disturbed communication the reset vector may be wrong -but I have never experienced it.

You have a slightly bigger chance to brick the bootloader, which reqires it to be reprogrammed by avrdude and an ISP or an Arduino as ISP. Command files for this can be found here.

Recommendedconfiguration

For ATtiny85, ATtiny88 and ATtiny167 the recommended configuration is t85_entry_on_powerOn_activePullup_fastExit.hex, t88_entry_on_powerOn_activePullup_fastExit.hex and t167_entry_on_powerOn_activePullup_fastExit.hex respectively.

This configuration has the following features:

  • A hardware reset (e.g., Digispark P5 shorted to ground or brownout happened) will always immediately run the user program.
  • If no user program is loaded, the LED quickly flashes indefinitely.
  • At power-on, we distinguish 3 cases.
  1. The board is connected to an USB. In this case, the bootloader waits for the host program (micronucleus.exe) to upload a program and starts the user program after around 1.5 seconds timeout or after upload completion. The built-in LED flashes while the bootloader is waiting for user program upload and during the upload phase (LED_MODE=ACTIVE_HIGH).
  2. The board is not connected to an USB. In this case, the bootloader starts the already installed user program after 600 milliseconds (FAST_EXIT_NO_USB_MS=300 means Fast exit of bootloader after 300+300 ms). The 600 ms are required to decide if there is an USB host attached or not.
  3. The board pull-up resistor supply is modified to be USB-VCC and not CPU-VCC and not connected to an USB or the pull-up resistor is removed. In this case, the pull-up is inactive and the bootloader immediately starts the installed user program (without startup delay, without hang-up and without affecting the internal LED at boot). This is referred to the ENTRY_D_MINUS_PULLUP_ACTIVATED part of the configuration flags. The builtin LED remains off in this case (LED_MODE=ACTIVE_HIGH has no effect here).

Hex files for these configuration are available in the releases and upgrades folders.

Create your own configuration

You can easily create your own configuration by adding a new firmware/configuration directory and adjusting bootloaderconfig.h and Makefile.inc. Before you run the firmware/make_all.cmd script, check the arduino directory path in the firmware/SetPath.cmd file.
If changes to the configuration lead to an increase in bootloader size, i.e. you see errors like address 0x2026 of main.bin section '.text' is not within region 'text', it may be necessary to change/decrease the bootloader start address as described in the next section and in the Makefile.inc.
Feel free to supply a pull request, if you added and tested a previously unsupported device.


Computing the bootloader start address

The actual memory footprint for each configuration can be found in the file firmware/build.log.
Bytes used by the mironucleus bootloader can be computed by taking the data size value in build.log, rounding it up to the next multiple of the page size which is e.g. 64 bytes for ATtiny85 and 128 bytes for ATtiny176.
Subtracting this (+ 6 byte for postscript) from the total amount of memory will result in the free bytes numbers.

  • Postscript are the few bytes at the end of programmable memory which store tinyVectors.

E.g. for t85_default.hex with the new compiler we get 1548 as data size. The next multiple of 64 is 1600 (25 * 64) => (8192 - (1600 + 6)) = 6586 bytes are free.
In this case we have 52 bytes left for configuration extensions before using another 64 byte page.
For data size from 1470 up to 1536 the address is 1A00 (6650 free), for 1538 to 1600 it is 19C0 (6586 free), for 1602 to 1664 it is 1980 (6522 free).

For t167_default.hex (as well as for the other t167 configurations) with the new compiler we get 1436 as data size. The next multiple of 128 is 1536 (12 * 128) => (16384 - (1536 + 6)) = 14842 bytes are free.
For data from 1281 to 1408 the address is 3A80, for size from 1409 to 1536 the address is 3A00


Bootloader memory comparison of different releases for t85_default.hex

  • V1.6 6012 bytes free
  • V1.11 6330 bytes free
  • V2.3 6522 bytes free
  • V2.04 6522 bytes free
  • V2.5 6650 bytes free

USB device manager entry / disconnect from USB

To avoid periodically disconnect->connect if no sketch is loaded and to avoid an unknown USB Device (Device Descriptor Request Failed) entry in device manager when entering user program, the bootloader finishes without an active disconnect from USB.
This means that you still can see a libusb-win32 decive / Digispark Bootloader in the Device manager, even when it is not alive, since your program has taken over the control of the CPU.
This behavior is compatible to the old v1 micronucleus versions, which also do not disconnect from the host. You can avoid this by actively disconnecting from the host by pulling the D- line to low for up to 300 milliseconds.
E.g a short beep at startup with tone(3, 2000, 200) will pull the D- line low and keep the module disconnected.


Reducing current of digispark bords for low power applications

Measured Digispark (ATtiny85 fast 64 MHz PLL clock) supply current

Current Voltage Clock Configuration
20 mA 5 V 16.5 MHz Standard Hardware
13 mA 3.8 V 16.5 MHz "
16 mA 5 V 8 MHz "
11 mA 5 V 1 MHz "
6 mA 3.8 V 1 MHz "
4.5 mA 3 V 1 MHz "
7.7 mA 5 V 1 MHz SLEEP_MODE_PWR_DOWN + ADC disabled
17 mA 5 V 16.5 MHz Voltage regulator removed
14 mA 5 V 16.5 MHz Power LED and voltage regulator removed
9.3 mA 5 V 8 MHz "
4.3 mA 5 V 1 MHz "
14.3 mA 5 V 16.5 MHz Power LED, voltage regulator removed + USB D- pull-up reconnected and powered directly at VCC (loop with delay)
9.5 mA 3.8 V 16.5 MHz "
8.3 mA 5 V 8 MHz "
7.5 mA 5 V 8 MHz All Hardware changes + empty loop + Timer and ADC disabled
3.0 mA 5 V 1 MHz All Hardware changes (loop with delay)
2.6 mA 3.8 V 1 MHz "
2.9 mA 5 V 1 MHz All Hardware changes + empty loop
2.4 mA 5 V 1 MHz All Hardware changes + empty loop + Timer and ADC disabled
230 µA 5 V 1 MHz All Hardware changes + SLEEP_MODE_PWR_DOWN
27 µA 5 V 1 MHz All Hardware changes + SLEEP_MODE_PWR_DOWN + ADC disabled + Watchdog enabled
25 µA 3 V 1 MHz "
7 µA 5 V 1 MHz All Hardware changes + SLEEP_MODE_PWR_DOWN + ADC disabled + BOD disabled + Watchdog enabled
5.5 µA 3.8 V 1 MHz " The Watchdog draws around 5 µA

BOD can only be disabled by setting fuses via ISP programmer](https://www.google.de/search?q=arduino+as+isp) and a connecting adapter. For reprogramming the fuses, you can use this script.

Current per device @ 5 volt

Current Device
3 mA Voltage regulator (1.5 mA at 3.8 V)
2 mA Power LED
1 mA USB D- pull-up
14.3 mA CPU + timer @16.5 MHz
14 mA CPU + timer @16 MHz
8 mA CPU + timer @8 MHz
3 mA CPU + timer @1 MHz
20 µA BOD
212 µA ADC
5 µA Watchdog

With fast PLL Clock and standard fuses, the start-up time from sleep is around 64ms and requires 2/3 of regular CPU power!
If we use the longest sleep time of 8 seconds and an empty loop, this result in an average current consumption of 23 µA (1 year with a 200 mAh button cell 2032).
The start-up time from sleep can be reduced (at own risk of unstable clock) to 5 ms using this fuse settings. This results in an average current consumption of 9 µA (2.5 years with a 200 mAh button cell 2032).
This startup time can even be reduced to 6 clock cycles by changing fuses to use the internal 8Mhz clock, but this disables the possibility to program the Digispark board via USB and and on the other hand removes the need for a bootloader and therefore leaves the whole memory for your program.

Modifying the board

Here is an Instructable covering the topic.

Disabling the power LED

Break the copper wire that connects the power LED to the diode with a knife or remove / disable the 102 resistor.

Removing the VIN voltage regulator

First, lift the outer pins with the help of a solder iron and a pin. Then solder the big connector and remove the regulator. For small regulators, use much solder and heat up all 3 pins together, then remove it.

Disconnecting the USB D- Pullup resistor (marked 152) from 5 volt (VCC)

Break the copper wire on the side of the resistor that points to the ATtiny.
This disables the USB interface and in turn the possibility to program the Digispark board via USB. To enable it again, but still save power, connect the resistor (marked 152) directly to the USB V+ that is easily available at the outer side of the schottky diode.
The diode and its correct sides can be found by using a continuity tester. One side of this diode is connected to pin 8 of the ATtiny (VCC) and Digispark 5V. The other side is connected to the USB V+.
Now the USB pull-up resistor is only activated if the Digispark board is connected to USB e.g. during programming.

Final power reduction

Another example for current reduction

Moddings:

  • Connect A to C (A is the right terminal of the 1kohm resistor; C is USB V+)
  • Cut B with a cutter (power supply rail interconnecting the 1kohm resistor with 5V)
  • Connect C with D (C is USB V+, D is the left terminal of the green LED resistor)
  • Remove the 78M05 linear regulator G
  • Connect E with F (short the two input/output terminals of the removed linear regulator)
  • Cut H with a cutter (power supply rail connecting 5V with the output of the linear regulator)

Now we have 3 power supply variants: 1 Use the USB to upload a sketch (the green LED is lighted) - Disconnect 5V and VIN. 2 Use 5V - GND to test the device with D- pull-up (the green LED is lighted) - Disconnect USB and VIN. 3 Use VIN - GND for standard operation in low current consumption. The power supply can be 3V to 5V (the green LED can be used as debug output of PB3). - Disconnect USB and 5V.


Pin layouts

ATtiny85 on Digispark

                       +-\/-+
 RESET/ADC0 (D5) PB5  1|    |8  VCC
  USB- ADC3 (D3) PB3  2|    |7  PB2 (D2) INT0/ADC1 - default TX Debug output for ATtinySerialOut
  USB+ ADC2 (D4) PB4  3|    |6  PB1 (D1) MISO/DO/AIN1/OC0B/OC1A/PCINT1 - (Digispark) LED
                 GND  4|    |5  PB0 (D0) OC0A/AIN0
                       +----+
  USB+ and USB- are each connected to a 3.3 volt Zener to GND and with a 68 ohm series resistor to the ATtiny pin.
  On boards with a micro USB connector, the series resistor is 22 ohm instead of 68 ohm.
  USB- has a 1.5k pull-up resistor to indicate a low-speed device.  
  USB+ and USB- are each terminated on the host side with 15k to 25k pull-down resistors.

ATtiny167 on Digispark pro

Digital Pin numbers in parenthesis are for ATTinyCore library

                  +-\/-+
RX   6 (D0) PA0  1|    |20  PB0 (D8)  0 OC1AU
TX   7 (D1) PA1  2|    |19  PB1 (D9)  1 OC1BU - (Digispark) LED
     8 (D2) PA2  3|    |18  PB2 (D10) 2 OC1AV
INT1 9 (D3) PA3  4|    |17  PB3 (D11) 4 OC1BV USB-
           AVCC  5|    |16  GND
           AGND  6|    |15  VCC
    10 (D4) PA4  7|    |14  PB4 (D12)   XTAL1
    11 (D5) PA5  8|    |13  PB5 (D13)   XTAL2
    12 (D6) PA6  9|    |12  PB6 (D14) 3 INT0  USB+
     5 (D7) PA7 10|    |11  PB7 (D15)   RESET
                  +----+
  USB+ and USB- are each connected to a 3.3 volt Zener to GND and with a 51 ohm series resistor to the ATtiny pin.
  USB- has a 1k5 pull-up resistor to indicate a low-speed device.
  USB+ and USB- are each terminated on the host side with 15k to 25k pull-down resistors.

MH-ET LIVE Tiny88 (16.0MHz) board

Digital Pin numbers in parenthesis are for ATTinyCore library

                        USB
                      +-\__/-+
               PA2  15|      |14  PB7
               PA3  16|      |13  PB5 SCK
           D17 PA0  A6|      |12  PB4 MISO
           D18 PA1  A7|      |11  PB3 MOSI
     (D17) D19 PC0  A0|      |10  PB2 OC1B/PWM SS
     (D18) D20 PC1  A1|      |9   PB1 OC1A/PWM
     (D19) D21 PC2  A2|      |8   PB0
     (D20) D22 PC3  A3|      |7   PD7 RX
SDA  (D21) D23 PC4  A4|      |6   PD6 TX
SCL  (D22) D24 PC5  A5|      |5   PD5
     (D23)     PC7  25|      |4   PD4
RESET          PC6 RST|      |3   PD3 INT1
LED            PD0   0|      |5V
USB-           PD1   1|      |GND
USB+  INT0     PD2   2|      |VIN
                      +------+
  USB+ and USB- are each connected to a 3.3 volt Zener to GND and with a 68 ohm series resistor to the ATtiny pin.
  USB- has a 1k0 pullup resistor to indicate a low-speed device.
  USB+ and USB- are each terminated on the host side with 15k to 25k pull-down resistors.

  Pins not available: PB6 is CLOCK_IN, PC7 is 25


Revision History

Version 2.6.0

  • Added compile flag STORE_CONFIGURATION_REPLY_IN_RAM.
  • Added 2 bytes USB config data for Bootloader feature flags and application version.
  • Added --info flag for micronucleus executable.

Version 2.5.2

  • Swapped D+ and D- again and set OSCCAL_HAVE_XTALfor t88 to support MH-ET LIVE Tiny88 boards.
  • Renamed the different pre-built configurations.
  • Saved 22 bytes by changing OSCCAL calibration function to Nerdralph's version.
  • Removed START_WITHOUT_PULLUP and extended FAST_EXIT_NO_USB_MS.
  • Executables are now included.

Version 2.5.1

  • Saved 28 bytes by #define USB_CFG_DESCR_PROPS_STRINGS 1. See #10, thanks to nerdralph.
  • Use 12 byted by re enabling push and pop of Y register in usbdrvasm165.inc. See #11.
  • Swapped D+ and D- for t88 to support MH-ET LIVE Tiny88 boards.

Version 2.5

  • Saved 2 bytes by removing for loop at leaveBootloader().

  • Saved 2 bytes by defining DELAY_BACKWARD_COMPATIBLE for _delay_ms().

  • Saved 22 bytes by converting USB_handler in usbdrvasm165.inc from ISR with pushes to a plain function.

  • Saved 2 bytes by improving small version of usbCrc16 in usbdrvasm.S.

  • Saved 4 bytes by inlining usbCrc16 in usbdrvasm.S.

  • Renamed AUTO_EXIT_NO_USB_MS to FAST_EXIT_NO_USB_MS and implemented it.

  • New configurations using FAST_EXIT_NO_USB_MS set to 300 ms.

  • Light refactoring and added documentation.

  • No USB disconnect at bootloader exit. This avoids "Unknown USB Device" entry in device manager.

  • Gained 128 byte for t167_default configuration.

  • Fixed wrong condition for t85 ENTRYMODE==ENTRY_EXT_RESET.

  • ATtiny167 support with MCUSR bug/problem at ENTRY_EXT_RESET workaround.

  • MCUSR handling improved.

  • no_pullup targets for low energy applications forever loop fixed.

  • USB_CFG_PULLUP_IOPORTNAME disconnect bug fixed.

  • New ENTRY_POWER_ON configuration switch, which enables the program to start immediately after a reset.

  • Copy MCUSR to GPIOR0 and clear it on exit for all ENTRY_POWER_ON and ENTRY_EXT_RESET configurations.

micronucleus-firmware's People

Contributors

arminjo avatar github-actions[bot] avatar ircama avatar spencekonde avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

micronucleus-firmware's Issues

[BUG] can't upload on Linux

Describe the bug
The board works on Windows with Digistump.Drivers
but on Linux it does not

To Reproduce
Steps to reproduce the behavior:

  1. use linux .
  2. follow http://digistump.com/wiki/digispark/tutorials/linuxtroubleshooting
  3. run "dmesg -w" as a root user
  4. you will see
    `[ 3154.154694] usb 3-3.2: new low-speed USB device number 22 using xhci_hcd

[ 3154.155066] usb 3-3.2: Device not responding to setup address.

[ 3154.363051] usb 3-3.2: Device not responding to setup address.

[ 3154.570687] usb 3-3.2: device not accepting address 22, error -71

[ 3154.650683] usb 3-3.2: new low-speed USB device number 23 using xhci_hcd
[ 3154.651052] usb 3-3.2: Device not responding to setup address.
[ 3154.859053] usb 3-3.2: Device not responding to setup address.
[ 3155.066671] usb 3-3.2: device not accepting address 23, error -71
[ 3155.066759] usb 3-3-port2: unable to enumerate USB device
`
5. try running "micronucleus --no-ansi --run --timeout 60 /tmp/arduino_build_110489/ATtiny85-note-play.ino.hex"

Please plug in the device (will time out in 60 seconds) ...

Expected behavior
"Device is found!"

Used Hardware
blue color digispark clone attiny85

Desktop (please complete the following information):

  • OS: Linux aorus 5.15.0-2-amd64 #1 SMP Debian 5.15.5-2 (2021-12-18) x86_64 GNU/Linux

  • Development environment --------

  • Version of the bootloader
    -Device has firmware version 2.6 Device signature: 0x1e930b Bootloader entry condition: The bootloader is activated if the D- pin is high, i.e. a pullup resistor is attached and powered and a power on condition was detected. Bootloader exit condition: The bootloader exits fast (< 1 second) if no USB detected. Available space for user applications: 6586 bytes

Unknown USB Device (Device Descriptor Request Failed) when running sketch without USB communication

Hi Armin,
When programming "upgrade-t85_default.hex" [V2.5, commit f90621b] into a DigiSpark and then uploading the DigiSpark "Start" example, USBtreeview shows the DigiSpark Bootloader for 6 secs and then shows Unknown USB Device (Device Descriptor Request Failed):

unknown device

I programmed the bootloader by: micronucleus.exe --run upgrade-t85_default.hex.
Micronucleus V1.11 showed only the Digispark Bootloader for 5 secs and then disappeared from USBtreeview [with sketch "Start" uploaded].
Is this a bug or is this intended behaviour with Micronucleus V2.5?

Regards,
Paul

USB_INT_VECTOR bug

Y must be saved according to the avr-libc calling convention, but you commented out the push instructions to save it.
https://github.com/ArminJo/micronucleus-firmware/blob/master/firmware/usbdrv/usbdrvasm165.inc#L41

And if you comment out the in YL, SREG line, you should clear it to make sure you don't get false timeouts at line 55 based on what YL happens to be before the function is called.
https://github.com/ArminJo/micronucleus-firmware/blob/master/firmware/usbdrv/usbdrvasm165.inc#L55

fast_exit_on_no_USB does not seem to work

Hi Armin,
As the subject says, the fast_exit_on_no_USB does not seem to work.
Using a genuine Digispark micro-USB board.
Steps to reproduce:

  1. https://github.com/ArminJo/micronucleus-firmware#installation-of-a-better-optimizing-compiler-configuration. Done.
  2. https://github.com/ArminJo/micronucleus-firmware#how-to-update-the-bootloader-to-the-new-version. Done.
    Is there a way to verify that the entry_on_power_on_no_pullup_fast_exit_on_no_USB bootloader has indeed been programmed?
  3. Upload the following sketch:
void setup() {
  pinMode(1, OUTPUT);   // LED on Model A  or Pro
  pinMode(3, OUTPUT);   // USB- signal
  digitalWrite(3, LOW); // pull USB- signal low, this avoids Unknown USB Device (Device Descriptor Request Failed)
}

void loop() {
  digitalWrite(1, HIGH);
  delay(100);
  digitalWrite(1, LOW);
  delay(100);
}
  1. After uploading, the sketch starts immediately.
Sketch uses 658 bytes (10%) of program storage space. Maximum is 6522 bytes.
Global variables use 9 bytes (1%) of dynamic memory, leaving 487 bytes for local variables. Maximum is 496 bytes.
Running Digispark Uploader...
Plug in device now... (will timeout in 60 seconds)
> Please plug in the device ... 
> Press CTRL+C to terminate the program.
> Device is found!
connecting: 16% complete
connecting: 22% complete
connecting: 28% complete
connecting: 33% complete
> Device has firmware version 2.5
> Device signature: 0x1e930b 
> Available space for user applications: 6522 bytes
> Suggested sleep time between sending pages: 7ms
> Whole page count: 102  page size: 64
> Erase function sleep duration: 714ms
parsing: 50% complete
> Erasing the memory ...
erasing: 55% complete
erasing: 60% complete
erasing: 65% complete
> Starting to upload ...
writing: 70% complete
writing: 75% complete
writing: 80% complete
> Starting the user app ...
running: 100% complete
>> Micronucleus done. Thank you!

But when you subsequently unplug & plug the board, it takes the regular 6 secs to start the sketch.

Regards,
Paul

Entry on reset - cannot reprogram the board

Hi,

I'm using Attiny85 and I accidentally burned 'Entry on reset' bootloader on it. Now my program runs, but device never goes into programming mode. I connect it via usb and my program uses HID. How can I fix this? I've seen some info about D- pin, but I can't find it on any pinout diagrams :)

drop strings to save 28 bytes

Although mn doesn't use vendor, product, or configuration strings, it still builds in string0 (language string descriptor). Removing this code, saves 28 bytes.
You can test it without actually removing the code by changing the config:
#define USB_CFG_DESCR_PROPS_STRINGS 1

A Ti85 with 1.11 where I can't flash 2.6 or charge program

Hi, I've marked this Digispark as faulty, I don't remember right, but I feel it couldn't be recognized by usb (it powered up but didn't dialogue); after about 6 months I've connected it back, it is recognized with version 1.11:

 Please plug in the device ...
> Device is found!
connecting: 20% complete
connecting: 27% complete
connecting: 34% complete
connecting: 40% complete
> Device has firmware version 1.11
> Available space for user applications: 6330 bytes
> Suggested sleep time between sending pages: 8ms
> Whole page count: 99  page size: 64
> Erase function sleep duration: 792ms
>> Micronucleus done. Thank you!

and if I try to upload 2.6 (which was sucessful on other Digisparks)

> Please plug in the device ...
> Device is found!
connecting: 20% complete
connecting: 27% complete
connecting: 34% complete
connecting: 40% complete
> Device has firmware version 1.11
> Available space for user applications: 6330 bytes
> Suggested sleep time between sending pages: 8ms
> Whole page count: 99  page size: 64
> Erase function sleep duration: 792ms
parsing: 60% complete
> Erasing the memory ...
erasing: 65% complete
erasing: 70% complete
erasing: 75% complete
erasing: 80% complete
> Starting to upload ...
writing: 85% complete
writing: 90% complete
writing: 95% complete
writing: 100% complete
>> Micronucleus done. Thank you!

but I still have the 1.11 version, why? The Ti85 doesn't look bricked, at least in the first stages, it communicates, there are no errors on flashing. Also I can't load nothing into it, Arduino IDE returns me:
>> Run error -1 has occured ...
There is nothing I can do to "revive it"? Thanks

The device on USB slist doesn't go off after some seconds, it stills there, the program doesn't start

USB Device Not Recognised

I flashed the t88 firmware to an "MH-Tiny MH-ET Live" board I bought off AliExpress, but when I connect it to USB I get the dreaded "USB Device Not Recognised" error.

The board works if I just flash the Blink sketch directly to it with a USBasp, so it's not that the chip is broken or anything.

There is a 16MHz crystal on-board, and I set the fuses to: L=0xE0, H=0xDC, E=0xFE

MH-Tiny board

DigiSpark doesn't respond within new environment[BUG]

Win10, installed the Driver and flashed one of several DigiSparks.
This seemed to work at first as the DigiSpark responded with a nerveous blinking LED. Something like 3-4 short blinks with a break of maybe half a second inbetween.

Then no success with flashing a new sketch onto the DigiSpark.
Also no success with flashing a new sketch onto an old DigiSpark with the old bootloader.
No success with using an Arduino UNO and/or an Arduino NANO as ISP.
Maybe partiall success with reflashing the bootloader via Arduino UNO as the the blinking-pattern disappeared after flashing. But then again no response to flashing a new sketch.

"No success" means: After compiling there comes the message to plug in the DigiSpark, and after doing this, no more reaction until timeout one minute later.

We had a nice and constructive conversation about this issue yesterday, but unfortunately, it has gone. Or at least I can't find it anymore to proceed. So I opened this issue which is maybe the right place to discuss thes kind of things.

firmware upgrade fails with checksum errors

%UserProfile%\AppData\Local\Arduino15\packages\digistump\tools\micronucleus\2.0a4\launcher -cdigispark -Uflash:w:upgrade-t85_default.hex:i
Running Digispark Uploader...
Plug in device now... (will timeout in 60 seconds)

Please plug in the device ...
Press CTRL+C to terminate the program.
Device is found!
connecting: 16% complete
connecting: 22% complete
connecting: 28% complete
connecting: 33% complete
Device has firmware version 1.6
Available space for user applications: 6012 bytes
Suggested sleep time between sending pages: 8ms
Whole page count: 94 page size: 64
Erase function sleep duration: 752ms
Warning: Checksum error between address 0x0 and 0x0
Warning: Checksum error between address 0x0 and 0xa
Warning: Checksum error between address 0xa and 0xa
Warning: Checksum error between address 0x0 and 0xde
Warning: Checksum error between address 0x0 and 0xde
Warning: Checksum error between address 0xa and 0xa
Warning: Checksum error between address 0xa and 0xa
Warning: Checksum error between address 0x0 and 0x0
Warning: Checksum error between address 0x0 and 0x0
Warning: Checksum error between address 0xace and 0xace
Warning: Checksum error between address 0xace and 0xace
Warning: Checksum error between address 0xace and 0xace
Warning: Checksum error between address 0xe and 0xe
Warning: Checksum error between address 0x0 and 0x0
Warning: Checksum error between address 0x0 and 0x0
Warning: Checksum error between address 0x2 and 0x2
Warning: Checksum error between address 0x0 and 0x0
Warning: Checksum error between address 0x0 and 0x0
Warning: Checksum error between address 0x0 and 0x0
Warning: Checksum error between address 0x0 and 0x0
Warning: Checksum error between address 0x0 and 0x0
Warning: Checksum error between address 0x0 and 0xd
Warning: Checksum error between address 0x0 and 0x0
Warning: Checksum error between address 0x0 and 0x0
Warning: Checksum error between address 0xca and 0xca
Warning: Checksum error between address 0x0 and 0x38
Warning: Checksum error between address 0xde and 0xde
Warning: Checksum error between address 0x5 and 0x1d
Warning: Checksum error between address 0xc and 0xc
Warning: Checksum error between address 0xa and 0xa
Warning: Checksum error between address 0x0 and 0x0
Warning: Checksum error between address 0x0 and 0xc
Warning: Checksum error between address 0xde and 0xde
Warning: Checksum error between address 0x0 and 0xa
Warning: Checksum error between address 0xa and 0xa
Warning: Checksum error between address 0x0 and 0xab
Warning: Checksum error between address 0x0 and 0x36
parsing: 50% complete
Erasing the memory ...
erasing: 55% complete
erasing: 60% complete
erasing: 65% complete
Starting to upload ...
writing: 70% complete
writing: 75% complete
writing: 80% complete
Starting the user app ...
running: 100% complete

Micronucleus done. Thank you!

Error compilin a new configuration t85

Hello! I'm trying to compile a new configuration (ENTRY_JUMPER) on attiny85 but i got the next error...
image

I'm using
Ubuntu 20.04
GNU Make 4.2.1
gcc (Ubuntu 9.3.0-17ubuntu1~20.04) 9.3.0

Thank you in advance!

programmer type jtagice3_updi not found

I have a blue color digispark clone and I'm trying to burn your bootloader , but got an error :

/home/bob/arduino-1.8.5/hardware/tools/avr/bin/avrdude -C/home/bob/.arduino15/packages/digistump/hardware/avr/1.7.5/avrdude.conf -v -pattiny85 -cstk500v1 -P/dev/ttyUSB1 -b19200 -Uflash:w:/home/bob/.arduino15/packages/digistump/hardware/avr/1.7.5/bootloaders/upgrade-t85_entry_on_powerOn_activePullup_fastExit.hex:i 

avrdude: Version 6.3, compiled on Jan 17 2017 at 11:00:16
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/home/bob/.arduino15/packages/digistump/hardware/avr/1.7.5/avrdude.conf"
avrdude: error at /home/bob/.arduino15/packages/digistump/hardware/avr/1.7.5/avrdude.conf:1142: programmer type jtagice3_updi not found
avrdude: error reading system wide configuration file "/home/bob/.arduino15/packages/digistump/hardware/avr/1.7.5/avrdude.conf"
Error while burning bootloader.

[BUG] Device search time-out after upgrading Attiny85 with recommended settings

Describe the bug
Firstly, I ran a couple of test programs on an Attiny85, and they worked without problems. But after updating the bootloader using the Arduino GUI with this project, the Attiny85 doesn't seem to get recognized by Windows anymore, although the on-board LED turns on.

These are the settings I used to flash the upgrade:
2022-03-08 22_59_34-

To Reproduce
Steps to reproduce the behavior:

  1. Set the bootloader upgrade settings according to the image
  2. Tools > Burn Bootloader
  3. Wait until the "Please plug in the device" message pops up
  4. Plug in Attiny85 via USB
  5. Wait until the process is finished
  6. Unplug Attiny85
  7. Wait 5 seconds
  8. Plug in Attiny85
  9. Wait 5 seconds //8.5 - realize that the previously flashed program is now gone
  10. Unplug the board
  11. Click the upload button on the Arduino IDE
  12. Wait until the "Please plug in the device" message pops up
  13. Plug in the board

Expected behavior
That the program gets flashed into the Attiny85.

Used Hardware
A regular Attiny85. connected to my laptop via USB.

Attempted Solutions

  • Restarting Windows (Windows gives a generic "USB device not recognized" error)
  • Flashing a known-to-work program (board is never detected by micronucleus)
  • Flash the bootloader again (board is never detected by micronucleus)

Desktop (please complete the following information):

  • OS:
Edition	Windows 10 Home Single Language
Version	21H1
Installed on	‎2020-‎09-‎18
OS build	19043.1526
Experience	Windows Feature Experience Pack 120.2212.4170.0
  • Development environment: Arduino IDE v1.8.19
  • Version of the bootloader:
    • (Latest) micronucleus-firmware v2.6.0
    • (Latest) DigistumpArduino v1.7.5

Should I have selected 16.5 MHz - For V-USB (Instead of 16 MHz - No USB) before making the bootloader upgrade?
How can I fix this? I'd really appreciate any clues you could give me

device search times out and platformio

I just tried to flash my digispark usb with platformio.

On the first try it found the usb device and started erasing. Unfortunately that got stuck and I assume the bootloader is gone - and now the device search just times out.

I guess that's related. I assume I will have to use a programmer to bring that back. (Any pointers appreciated!)

And while I am at it - maybe I could go for this firmware instead?
How could one use this firmware with platformio?

https://docs.platformio.org/en/latest/platforms/atmelavr.html#bootloader-programming

Digispark not recognized on Linux machine, but only at boot.

Hello,
This is not really an issue with your firmware (that I successfully installed on the board), but more a help request :)
In fact I've been having this issue even with the micronucleus version pre-installed (v1.6, IIRC).

Basically, if the board is already connected via USB, early at boot the only message I see with dmesg is:

[    1.500000] usb 3-2: new low-speed USB device number 3 using xhci_hcd
[    1.600000] usb 3-2: device descriptor read/64, error -71

...and nothing works. The device remains unresponsive (and the led is fixed ON).

If the device is plugged after the machine booted, all goes well:

[   70.858428] usb 3-2: new low-speed USB device number 10 using xhci_hcd
[   71.008647] usb 3-2: New USB device found, idVendor=16d0, idProduct=0753, bcdDevice= 2.05
[   71.008649] usb 3-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[   76.921597] usb 3-2: USB disconnect, device number 10

and then after 6 seconds:

[   77.441563] usb 3-2: new low-speed USB device number 11 using xhci_hcd
[   77.901798] usb 3-2: New USB device found, idVendor=16c0, idProduct=27db, bcdDevice= 1.00
[   77.901805] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[   77.901808] usb 3-2: Product: DigiKey
[   77.901811] usb 3-2: Manufacturer: digistump.com
[   78.022308] input: digistump.com DigiKey as /devices/pci0000:00/0000:00:14.0/usb3/3-2/3-2:1.0/0003:16C0:27DB.0003/input/input28
[   78.082004] hid-generic 0003:16C0:27DB.0003: input,hidraw2: USB HID v1.01 Keyboard [digistump.com DigiKey] on usb-0000:00:14.0-2/input0

Do you have any suggestion in regards?
Thanks.

your fork

Hi Armin,

it is true that the current maintainers of Micronucleus do not manage to dedicate the time to the project it deserves. If you want to become part of the maintainer team you are very welcome to! (I don't think @Bluebie @AHorneffer object). The main ask would be that some continuity is kept in revisioning and versions are tagged accordingly. I think creating a fork, especially with the message you added, will only add to confusion.

Best regards,
Tim

Warnings when verifying sketch Mouse.ino

Describe the bug
Any tips how to correct these warnings?

In file included from C:\Users\user\AppData\Local\Temp\.arduinoIDE-unsaved2023128-17736-1rbdovb.3jug\Mouse\Mouse.ino:5:0:
C:\Users\user\AppData\Local\Arduino15\packages\digistump\hardware\avr\1.7.5\libraries\DigisparkMouse/DigiMouse.h: In function 'unsigned char usbFunctionDescriptor(usbRequest*)':
C:\Users\user\AppData\Local\Arduino15\packages\digistump\hardware\avr\1.7.5\libraries\DigisparkMouse/DigiMouse.h:323:18: warning: invalid conversion from 'const unsigned char*' to 'unsigned char*' [-fpermissive]
      usbMsgPtr = rt_usbDeviceDescriptor;
                  ^~~~~~~~~~~~~~~~~~~~~~
C:\Users\user\AppData\Local\Arduino15\packages\digistump\hardware\avr\1.7.5\libraries\DigisparkMouse/DigiMouse.h:328:18: warning: invalid conversion from 'const unsigned char*' to 'unsigned char*' [-fpermissive]
      usbMsgPtr = rt_usbHidReportDescriptor;
                  ^~~~~~~~~~~~~~~~~~~~~~~~~
Sketch uses 2802 bytes (42%) of program storage space. Maximum is 6586 bytes.
Global variables use 92 bytes (17%) of dynamic memory, leaving 420 bytes for local variables. Maximum is 512 bytes.

It seems to happen even when verifying Mouse.ino example sketch.

To Reproduce
Steps to reproduce the behavior:

  • Open example sketch: Mouse.ino
  • Select board: Digispark
  • Select clock: 16.5 MHz (For V-USB)
  • Select Micronucleus variant: Entry on reset
  • Select programmer: micronucleus.2.5
  • Verify sketch.

Expected behavior
Clean verify/upload.

Used Hardware
Digispark (clone)

Desktop (please complete the following information):

  • OS: Win10 Pro x64
  • Development environment: Arduino IDE 2.0.4
  • Version of the bootloader: 2.6.1

Avoid waiting for USB if D- is not pulled up

I think that if the USB D- pullup is removed to save energy, the USB should not work. At least, this is what I see from my tests.

With Digispark, in order to have the USB working when its socket is connected (device powered by USB) and at the same time no pull-up consumption without USB (e.g., with the device powered through +5V or VIN), the USB D- pull-up resistor should be directly connected to USB V+ and not to +5V: considering that there is a diode between USB V+ and +5V, the pullup will be powered (by USB V+) when the USB is connected and not applied when the USB is disconnected and the device is powered elsewhere (e.g., via Digispark 5V or VIN pins); this is because current does not flow from 5V to the pullup resistor but only through the opposite direction (which is from USB V+ to the pullup resistor directly and to +5V via the diode).

This means that if ENTRY_POWER_ON is selected (as well as START_WITHOUT_PULLUP) and the bootloader does not see PB3 pulled up at boot (which means that the USB is not connected and, in any case, there should not be the possibility to use USB without pullup), the bootloader should not try to start the USB (even within the current short time of the recommended configuration) and the LED should not flash at all.

Is there a way to set up such configuration as an upgrade to the recommended configuration?

avrdude: verification error, first mismatch at byte 0x3a00

I'm trying to flash the micronucleus bootloader into a digispark Pro board.
I have updated the Makefile to use the usbtiny programmer that I have.
After connecting the programer, and building the main.hex with the config t167_entry_n_powerOn_activePullup_fastExit, and try to flash it, but I get a verification error:

:[firmware](master)$ make CONFIG=t167_entry_on_powerOn_activePullup_fastExit flash
avrdude -c usbtiny -p attiny167  -U flash:w:main.hex:i -B 20

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e9487 (probably t167)
avrdude: NOTE: "flash" memory has been specified, an erase cycle will be performed
         To disable this feature, specify the -D option.
avrdude: erasing chip
avrdude: reading input file "main.hex"
avrdude: writing flash (16224 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 16224 bytes of flash written
avrdude: verifying flash memory against main.hex:
avrdude: load data flash data from input file main.hex:
avrdude: input file main.hex contains 16224 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x3a00
         0xff != 0x16
avrdude: verification error; content mismatch

avrdude: safemode: Fuses OK (E:FE, H:DD, L:DF)

avrdude done.  Thank you.

make: *** [Makefile:61: flash] Error 1

I also tried changing the BOOTLOADER_ADDRESS to 3A80 but same result.

Any help will be appreciated!

Compile error

I'm having a problem compiling the firmware:

upgrade.c: Na função ‘write_new_bootloader’:
upgrade.c:94:23: erro: ‘bootloader_size’ undeclared (first use in this function)
while ( page_addr < bootloader_size ) {
^
upgrade.c:94:23: nota: each undeclared identifier is reported only once for each function it appears in
upgrade.c:98:32: erro: ‘bootloader’ undeclared (first use in this function)
int subaddress = ( (int) bootloader ) + page_addr + word_addr;
^
upgrade.c:99:33: erro: ‘bootloader_end’ undeclared (first use in this function)
if ( subaddress < ( (int) bootloader_end ) ) { // valid boot code
^
upgrade.c:107:17: erro: ‘bootloader_address’ undeclared (first use in this function)
erase_page( bootloader_address + page_addr );
^
upgrade.c: Na função ‘forward_interrupt_vector_table’:
upgrade.c:153:39: erro: ‘bootloader_address’ undeclared (first use in this function)
vector_table[ iter ] = 0xC000 + ( bootloader_address / 2 ) - 1;
^
make: *** [Makefile:117: upgrade.o] Error 1

[ENHANCEMENT] RESET pin defined as output (original digispark?)

On the main page, it states that the default hFuse on a digispark is 0xDD.
From what I read on the digispark forum, the original digispark has the hFuse set to 0x5D, thus allowing all 6 Pins to be used for I/O.
To flash a program to the chip, PB0 must be connected to GND then.
A 6th I/O pin is very valuable, and I am missing a hex file with this feature in the precompiled files.
I know that disabling the RESET pin also disables any further ISP programming, but as the programming is done via USB this is not so much of a drawback.
There are also many instructables how to build a simple HV fuse resetter with an arduino, in case one needs ISP programming.
I am a Windows user and if I know how to burn a hex file, but I do not know how to compile an adapted multinucleus core.
Thus, I would very much appreciate, if there was at least a single precompiled hex file which has the 6 I/O pins enabled.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.