Digispark CDC library doesn't work

[arminjo]

Digispark CDC library doesn't work

[maxgerhardt]

The general DigisparkUSB and also DigisparkCDC library use V-USB as the underlying USB library, and it also has a few words on CDC

CDC requires bulk endpoints which are forbidden for low speed devices by the USB specification. However, most operating systems don't care and CDC works

which we don't observe here.. so I'm not sure if any USB CDC actually works on modern operating system with non-hacked drivers with the low-speed AVRs.

On the other hand, here's a echo example, from what I see it uses a generic HID USB class here. The USB functions HID set report and HID get report are used to transfer data to the device. And this looks like a nice easy tool to send and receive HID reports for data exchange. Maybe you can even use libusb or some python libs.

[brandsimon]

Long story short, I got it working, at least for my use-case. Since the plain echo-sketch ( https://gist.github.com/brandsimon/0cf7166eefb2282bbeaa405f8cac8f8c#file-echo-ino ) worked (more or less) reliable with less then 36 characters, I took time to dig deeper. It turns out, that the device does still work after the first 8 characters, if a character is sent back. Since my communication is line-based, I choose the new line character.
Here is my working solution:
https://gist.github.com/brandsimon/0cf7166eefb2282bbeaa405f8cac8f8c#file-serial-ino

Here is my longer story, I wrote down some of my observations as I made them:
My digispark also has unreliable input after 36 characters with the echo sketch: https://gist.github.com/brandsimon/0cf7166eefb2282bbeaa405f8cac8f8c#file-echo-ino
Here is a reproducible example input/output:

123456789abcdefghijklmnopqrstuvwxyz987654321
123456789abcdefghijklmnopqrstuvwxyz94

I improved the situation a bit by increasing the RX ring buffer size, but the board does still not work reliable. The problem is definitely the receiving side, since a lot of longer hard-coded prints work like a charm.
If you have issues, keep in mind to call SerialUSB often enough, see the digistump wiki: https://digistump.com/wiki/digispark/tutorials/digicdc

SerialUSB.delay() or SerialUSB.refresh() must be called every 10ms or less in your code if no other SerialUSB call is made in that code.

@RaduTek

I'm curious if we can update the V-USB part of DigisparkCDC, as it may be an older version.

I just copied the files from master:v-usb/usbdrv to .arduino15/packages/.../DigisparkCDC/. The only change needed is in DigiCDC.h:
Wrap #include "usbdrv.h" in extern "C":

extern "C" {
#include "usbdrv.h"
}

However it did not fix my problem. The changes seam also quite minor to me.

When I got my digispark, I had problems on one laptop, while another worked fine. After some research I found out that these problems are common. The bitbanged USB support is known to be unreliable due to timing issues. However, using a USB-hub did not solve my issue with DigiCDC.
micronucleus/micronucleus#94 (comment)
https://digistump.com/board/index.php?topic=1622.msg7497#msg7497
https://arduino.stackexchange.com/questions/89921/anyone-had-digispark-attiny85-not-seen-by-some-usb-controllers-but-seen-via-hub

Since I thought the problem is related to timing issues, I tried to fix them in the usbdrvasm165.inc with no luck.
I found out, that the internal oscillator can be calibrated: https://codeandlife.com/2012/02/22/v-usb-with-attiny45-attiny85-without-a-crystal/
Sadly this code is already integrated in osccal.c and used in the DigiCDC.
So I tried to play with OSCCAL and see if something changes. The default for my digispark is a value of 157 or 158. The USB-stack crashes below 153 and above 163, so 158 is probably the optimal value.
Here is a sketch if you want to play around with the OSCCAL setting. https://gist.github.com/brandsimon/0cf7166eefb2282bbeaa405f8cac8f8c#file-osccal-ino
Example output: https://gist.github.com/brandsimon/0cf7166eefb2282bbeaa405f8cac8f8c#file-osccal_output-txt

In my research I found out that all rev3 boards of the digispark are counterfeit https://digistump.com/wiki/digispark/quickref and sadly I have one of them. I have the impression, that digistump did not produce digisparks for years. So I don't know if I have problems because of cheap/wrong parts in my digispark.

I also have a weird behavior when using a big global variable: https://gist.github.com/brandsimon/0cf7166eefb2282bbeaa405f8cac8f8c#file-echo_broken-ino
If BRICK is defined, the variable is global and the board will crash after 4 sent characters. When it is undefined, the variable is local and everything works.
I don't know if this is a bug in the old gcc?

[maxgerhardt]

Very interesting: the DigisparkKeyboard/Keyboard.ino demo works and the computer recongizes the USB device. But not with the CDC sketch..

[maxgerhardt]

The DigiUSB/DigiBlink.ino works as well.

But not the CDC :/

[d-a-v]

FWIW, CDC (serial port) works but is very unstable under Linux (it makes eventually the Linux general host USB stack hang).

[ArminJo]

@d-a-v Thanks for the info.
I never tested CDC and do not know the development state, I just delivered the original digistump version.

[maxgerhardt]

The same behavior occurrs btw with the original core (https://github.com/digistump/DigistumpArduino/).

There are some forum topics about this (http://digistump.com/board/index.php/topic,2720.msg13422.html#msg13422) with some posts like

DigiCDC is an ugly hack, as CDC devices are specified as Hi-Speed USB (12 MHz clock). The Digispark USB emulation is Lo-Speed USB (1.5 MHz clock). It worked anyway on Windows XP and on older Linux kernels, but with newer versions of Windows and Linux it does not work anymore.

Another post (http://digistump.com/board/index.php/topic,2321.msg13159.html#msg13159) talks about deactivating Windows's driver signing and installing a magic driver (https://github.com/protaskin/LowCDC-Win10x64). I don't want to risk a BSOD like in the issue of that repo though 😅.

[ArminJo]

So I think, it is a good idea to extend the examples with these links and a warning. I will do this...

Update: Done 😀

[GiorgosXou]

Is there any alternative way of serial communication directly from usb? or at least any other possible software based way, except from deactivating Windows's driver signing? (I'm looking for a way to communicate between a Digispark and a PC's USB port)

^{it’s been bugging me for hours now..}

[d-a-v]

Has anyone ever tried TinyUSB with this core ?

[GiorgosXou]

Personally, I wish i could but my knowledge on this subject is quite a bit baffled... and so I'm not that sure about how i could manage to get it working right now [...]

[wujiang]

Not working for me either. Anyone has any recommendations for some similar libraries?

[simonovich]

I recommend cleaning the chip manually first.
It seems to me that this does not happen when writing firmware from Arduino IDE

This command will clear the chip.
Specify your details for paths, port and port speed:

~/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino18/bin/avrdude -e -c arduino -p t85 -P /dev/ttyUSB0 -b 19200 -C ~/.arduino15/packages/arduino/tools/avrdude/6.3.0-arduino18/etc/avrdude.conf

Then return to IDE and try flashing the chip again.

[maxgerhardt]

@simonovich so you have the situation that it does work in the Arduino IDE but not over PlatformIO, or have you not tested it via PlatformIO?

[simonovich]

have you not tested it via PlatformIO?

Sorry, I don't know anything about PlatformIO.
I did it in Arduino IDE

[amckinlay]

None of the DigisparkCDC examples are working on macOS. Please remove them. There is no way to get Arduino's Serial Monitor to work.

[simonovich]

I have Ubuntu LTS.
And I made Didispark ATtiny85 work!
I don't fully understand where the error is.
But there are steps that will lead to success.
It is necessary to carry out all operations as carefully as possible.
And then the board will work.

[simonovich]

There are questions about the work of Serial on CDC.
But I think that the error is somewhere in my code and the firmware is not to blame.
For example, this code hangs if a string of more than 6 characters is entered

//...
void loop() {
  serial_tick();
}
// ...
void serial_tick() {
  if (SerialUSB.available()) {
    char input = SerialUSB.read();
    SerialUSB.delay(2);
    if (input == '1')
      rmtBtn = true;
    else if (input == '0')
      rmtBtn = false;
  }
}

[RaduTek]

I recall having gotten DigisparkCDC to work in the past on modern Windows but I have no idea how I did it.

I tried now to change some of the settings in the the usbconfig.h file of the DigisparkCDC library and I have gotten it to show up correctly on the computer, but loading the driver resulted in a SYSTEM_THREAD_EXCEPTION_NOT_HANDLED BSoD from the hacky lowcdc.sys driver (on Windows 11 Insider Beta build 22000.527)

I changed the setting on line 328 from #define USB_CFG_DESCR_PROPS_CONFIGURATION USB_PROP_IS_DYNAMIC to #define USB_CFG_DESCR_PROPS_CONFIGURATION 0 as it was set to 0 in the DigiUSB library's usbconfig.h file.

[RaduTek]

I will try to install the driver on older versions of Windows and give updates.

I'm curious if we can update the V-USB part of DigisparkCDC, as it may be an older version.

• On Windows XP, it complains about the service configuration section of the INF being incorrect and it also doesn't recognise the driver as being digitally signed. I'll have a go at modifying the INF file to see if I can fix it.
• On Windows 7 it gives the same service configuration section error.

So I have figured out the driver install error, the driver was attempting to install a service using the usbser.sys binary from Windows, but it wasn't calling for Windows to install that file correctly, so if no other USB Serial devices were installed previously that file would not be there.
After installing the file and installing the driver, it throws the SYSTEM_THREAD_EXCEPTION_NOT_HANDLED BSoD.

When the USB_CFG_DESCR_PROPS_CONFIGURATION is set to USB_PROP_IS_DYNAMIC in the usbconfig.h file of the DigisparkCDC library, it works just fine on Windows XP.