How to program ATtiny 85 with PlatformIO / VScode?

Development Platforms
1

After many ESp & Ardiono projects, I wanted to try ATtiny 85, with DigiSpark USB.
The original platformio.ini:

    [env:digispark-tiny]
    platform = atmelavr
    board = digispark-tiny
    framework = arduino

Compilation passed, yet with many “yellow” errors like the errors below.

When I try to upload, I get:

    Uploading .pio\build\digispark-tiny\firmware.hex
    *** [upload] Error 309

Any idea how to solve this?
Thank you
Yigal

The warnings:

In file included from C:\Users\NH5\.platformio\packages\framework-arduino-avr-digistump\cores\dtiny/Stream.h:24:0,
                 from C:\Users\NH5\.platformio\packages\framework-arduino-avr-digistump\cores\dtiny/TinyDebugSerial.h:31,
                 from C:\Users\NH5\.platformio\packages\framework-arduino-avr-digistump\cores\dtiny/WProgram.h:18,
                 from C:\Users\NH5\.platformio\packages\framework-arduino-avr-digistump\cores\dtiny/arduino.h:4,
                 from src\main.cpp:2:
C:\Users\NH5\.platformio\packages\framework-arduino-avr-digistump\cores\dtiny/Print.h:37:0: warning: "BIN" redefined
 #define BIN 2
 ^
In file included from c:\users\nh5\.platformio\packages\toolchain-atmelavr\avr\include\avr\iotn85.h:38:0,                 from c:\users\nh5\.platformio\packages\toolchain-atmelavr\avr\include\avr\io.h:428,     
                 from c:\users\nh5\.platformio\packages\toolchain-atmelavr\avr\include\avr\interrupt.h:38,
                 from C:\Users\NH5\.platformio\packages\framework-arduino-avr-digistump\cores\dtiny/WProgram.h:8,
                 from C:\Users\NH5\.platformio\packages\framework-arduino-avr-digistump\cores\dtiny/arduino.h:4,
                 from src\main.cpp:2:
c:\users\nh5\.platformio\packages\toolchain-atmelavr\avr\include\avr\iotnx5.h:55:0: note: this is the location of the previous definition
 #define BIN     7
 ^
Archiving .pio\build\digispark-tiny\libFrameworkArduinoVariant.a
In file included from C:\Users\NH5\.platformio\packages\framework-arduino-avr-digistump\cores\dtiny/wiring_private.h:32:0,
Compiling .pio\build\digispark-tiny\FrameworkArduino\TinyDebugSerial.cpp.o
                 from C:\Users\NH5\.platformio\packages\framework-arduino-avr-digistump\variants\digispark\pins_arduino.c:38:
c:\users\nh5\.platformio\packages\toolchain-atmelavr\avr\include\avr\delay.h:36:2: warning: #warning "This file has been moved to <util/delay.h>." [-Wcpp]
Compiling .pio\build\digispark-tiny\FrameworkArduino\TinyDebugSerial115200.cpp.o
 #warning "This file has been moved to <util/delay.h>."
2

Looks like whoever wrote the file iotnx5.h redefined the macro BIN which is defined in the Arduino core. This is not good!

The others are warnings to let you know that including delay.h has been superceeded and younshould be including util/delay.h instead.

If the problem isn’t in your code, then it sounds like your library(?) Might be out of date and needing an update by the author.

Regarding the errorn309 problem, I used to haveva Digispark years ago with an ATtiny85 but sadly, I bricked it when I set the fuses!

It used to have a weird bootloader with prompted me to do something, plug it in I tjink, when uploading.

Do you get that prompt when you try to upload?

Can you upload a standard blink sketch without problems?

By the way, I edited your post to wrap the code and error sections in triple backticks:

```
Like this...
```

As it makes things more readable and prevents bits of the text from disappearing due to Windows backslashes or ‘<’ and/or ‘>’ etc.

Cheers,
Norm

3

You have the board http://digistump.com/products/1?

Me too.

But you need to install drivers first from Releases · digistump/DigistumpArduino · GitHub (then Install Drivers.exe)

Then you have to unplug the device from the USB port and hit “Upload” (Or Advanced → Verbose Upload).

The commandprompt will ask you

micronucleus -c micronucleus --timeout 60 .pio\build\digispark-tiny\firmware.hex
> Please plug in the device ...

and once you do that…

> Press CTRL+C to terminate the program.
> Device is found!
connecting: 20% complete
connecting: 27% complete
connecting: 34% complete
connecting: 40% 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
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!
==================== [SUCCESS] Took 10.13 seconds ====================

The compile warnings aren’t too critical, the wrong BIN definition goes unused in the header file.

You can test the blinky LED with

#include <Arduino.h>

/* LED is on chip's PB1 pin which maps to D1 arduino pin*/
#define LED 1

void setup()
{
  pinMode(LED, OUTPUT);
}

void loop()
{
  digitalWrite(LED, HIGH);
  delay(500);
  digitalWrite(LED, LOW);
  delay(500);
}

Just be aware that after upload the bootloader will sit for a short time and wait for a new upload (5 secs), then after will the firmware start.

You always have to plug and unplug that board for uploading, per http://digistump.com/wiki/digispark/tutorials/connecting, since you don’t get into the bootloader otherwise…

Edit: I’ve tried and get the USB-CDC working with help from DigiSpark compilation failure using CDC library - #2 by maxgerhardt but it doesn’t seem to be working anymore – Windows just reports a USB device error (getting descriptor failed). Maybe you have more luck or insights.

3 Likes
4

Yes - exactly. This is my device.

And thank you - after installing drivers it is working well.

5

Thanks Norman.
You are right, the delay() is not recommended any more. I use milies(), but when I need to check something and not for “production”, I get lazy and use delay().
I didn’t know there is a delay.h lib, I will search for it.

Now that upload is completed, and my sketch is working. Thanks !

6

I might have too happy too soon. I installed the drivers and did the first programming, I cant up load any more. When I press (within VS code) upload, I don’t get the “please plug the device” message.
What am I doing wrong?

7

Only shows up during Verbose Upload I discovered. But the firmware will still upload as normal with “Upload”, just doesn’t show you a message to plug it in.

8

The upload keeps failing, I changed the leds blink (3 colors) and it is still the same old blink mode.
How do I set the “verbose”? Didn’t find on PlatformIO/VScode.

The error:
Configuring upload protocol…
AVAILABLE: micronucleus
CURRENT: upload_protocol = micronucleus
Uploading .pio\build\digispark-tiny\firmware.hex
> Please plug in the device …
> Press CTRL+C to terminate the program.
> Device search timed out
*** [upload] Error 1

9

grafik

Seems like it couldn’t find the USB device or the driver is screwing up. There’s a timeout of 60 seconds. Have you unplugged the device before the upload and then plugged it in?

You can also open the Windows device manager. If you plug the device in (and the drivers are installed), you must see

grafik
grafik781×572 25 KB

it under the libusb-win32-devices.

10

Thanks for the verbose guidance. I can see it now.

As for the driver - you are probably right - when I plug it, it is recognized as “unknown USB device”. I tried re-installing the drivers , re-boot - so far no luck.

I use the dpinst64 from [http://digistump.com/wiki/digispark/tutorials/connecting]

I also tried uninstalling the device from the device manager, yet I am not sure it is removing the previous driver.

11

The wiki links Installing Drivers and Programming the DigiSpark ATtiny85 dev boards - Tutorial - YouTube where it shows that you might be able to quickly (I mean the bootlaoder is only on for 5 secs…?) install the right driver in the device manager using the path to the unzipped driver folder.

12

I followed the video (exactly as I did before), and I still get the same (A request for the USB device descriptor failed.).
Perhaps the bootloader within the Attiny is somehow damaged? The part that is communicating with the Windows USB when plugged in?

13

Hmm I’ve read a few things at https://www.reddit.com/r/arduino/comments/6b5djs/having_trouble_installing_digispark_attiny85/ and https://digistump.com/board/index.php?topic=1959.0 and their forum search in general (http://digistump.com/board/index.php?action=search2) but no conclusive answer besides try and reinstall the driver within 5 seconds, use a different USB port / cable, uninstall / reinstall driver, from some chinese clone the USB resistors / shell fell of and was defective etc. :confused:

Since it works for me (at least the bootloader + uploading), I can’t reproduce it. You might find help in https://digistump.com/board/index.php or Issues · digistump/DigistumpArduino · GitHub.

There’s also the posibility of programming a barebones ATTiny85 with an external programmer but that then also defeats the purpose of using the Digistump. See e.g. Programming ATtiny85 IC directly through USB without Arduino using Digispark Bootloader or Tiny AVR Programmer Hookup Guide - SparkFun Learn.

14

Problem (partially) solved.
It looks like I did the basic mistake of wrong assumptions - I added an ultrasonic sensor, using pins 4 as Echo (input) and 5 as trig (output). Looking at the datasheet, pin 4 is USB- and 3 is USB+. So probably pin 4, driven by the sensor, corrupts the USB connection. Once removing it, the driver is working well, and I can program it properly.
Perhaps I need to get used to programming the Attiny with external socket. if I need the pins, or make sure pins 3’4 will not drive any value for start (put a delay in setup?)

2 Likes
15

I think having the ultrasonic sensor attached alone to the board has caused this. The sensor will need extra current at startup and might be pulling the supply low, or the input pin of the sensor has some pull-down/pull-up logic which messes with the criticial USB- line which has some pullup/down network attached to it (see https://s3.amazonaws.com/digispark/DigisparkSchematicFinal.pdf on USB_M signal). If that’s the case then a delay will also not help because it doesn’t alter that the USB- line is loaded electrically differently now.

Re-allocating to a different pin or unplugging it before a new upload should solve it.

2 Likes
16

@ byigal

Because of these warnings and the fact that there is no EEPROM library coming with the digistump package I switched the core package to (native?) tiny. If you are interested you can have a look at the work in progress project at IoT-Universal-Socket-Strip/software/relay at master · anno73/IoT-Universal-Socket-Strip · GitHub. So far everything went well aslong you take care of some things (like already mentioned using USB lines for your purpose).

17

Because of link limit for new users another post:

I also filed an issue about the warnings Digistump digispark ATTiny85 compile time noise · Issue #233 · platformio/platform-atmelavr · GitHub but the community is rather unresponsive.

18

This doesn’t work for me.

I’m using the Digispark ATTiny85 but have an issue with the drivers.

Here’s what I see in PlatformIO

Building in release mode
Checking size .pio\build\attiny85\firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
RAM:   [          ]   1.8% (used 9 bytes from 512 bytes)
Flash: [=         ]   5.7% (used 464 bytes from 8192 bytes)
Configuring upload protocol...
AVAILABLE: micronucleus
CURRENT: upload_protocol = micronucleus
Uploading .pio\build\attiny85\firmware.hex
*** [upload] Error 3221225781

You can see that the message Please plug in the device... is missing

Going to the device manager I don’t see any unknown device under Other devices

How do I make sure any prior drivers are removed and how do I install the correct drivers for the ATTiny85? Could it be that the bootloader is missing on the ATTiny85?

19

This status code is STATUS_DLL_NOT_FOUND tells you that the uploader executable couldn’t even execute because you’re missing DLLs it needs.

You can use http://dependencywalker.com/ to try and detect what DLLs it needs and which one you don’t have. It may be something like Visual C/C++ redistributables.

20

Or well, just locating the micronucleus.exe executable in C:\Users\<user>\.platformio\packages\tool-micronucleus and running it should also tell you what it needs, in my case,

image

it’s libusb0.dlll.

You can get that from the latest Micronucleus release.