1 |
On Sun, Aug 6, 2017 at 11:50 AM, <tuxic@××××××.de> wrote: |
2 |
> When I plug in such a little board into my PC, demesg |
3 |
> reports: |
4 |
> [ 1429.834140] usb 7-4: new low-speed USB device number 15 using ohci-pci |
5 |
> [ 1429.965142] usb 7-4: device descriptor read/64, error -62 |
6 |
> [ 1430.203151] usb 7-4: device descriptor read/64, error -62 |
7 |
> [ 1430.438161] usb 7-4: new low-speed USB device number 16 using ohci-pci |
8 |
> [ 1430.569151] usb 7-4: device descriptor read/64, error -62 |
9 |
> [ 1430.803174] usb 7-4: device descriptor read/64, error -62 |
10 |
> [ 1431.038184] usb 7-4: new low-speed USB device number 17 using ohci-pci |
11 |
> [ 1431.456157] usb 7-4: device not accepting address 17, error -62 |
12 |
> [ 1431.582204] usb 7-4: new low-speed USB device number 18 using ohci-pci |
13 |
> [ 1432.000209] usb 7-4: device not accepting address 18, error -62 |
14 |
> [ 1432.000244] usb usb7-port4: unable to enumerate USB device |
15 |
> |
16 |
|
17 |
> |
18 |
> My first thought was: The micronucleus bootloaed is missing or |
19 |
> is defective... |
20 |
> |
21 |
> But plugging in the board into my Android tablet (the tablet runs |
22 |
> Lollipop and is nothing special at all beside being rooted) via |
23 |
> an OTG cable and using lsusb after that, it shows |
24 |
> Bus 001 Device 003 ID 16d0:0753 MCS Digistump DigiSpark |
25 |
> |
26 |
|
27 |
What the dmesg output is saying is that your USB hardware has reported |
28 |
a communication error to the driver. It is my guess that the ATtiny85 |
29 |
is not meeting the timing requirements for USB. |
30 |
|
31 |
Looking at the board there does not seem to be a crystal oscillator |
32 |
which most people would consider necessary for doing USB |
33 |
communication. This is an oversight on DigiStump's part and it is very |
34 |
likely you will not be able to fix the communication issues. You |
35 |
should contact them and tell them that your computer will not |
36 |
recognize their device and that you suspect it is because the clock is |
37 |
too inaccurate. |
38 |
|
39 |
> |
40 |
> What can I do to make this Digispark being correctly recognized? |
41 |
> |
42 |
> Thank you VERY much for any help in advance! |
43 |
> |
44 |
|
45 |
Three things: |
46 |
|
47 |
1) Return the one you bought and get a new one. The ATtiny85's |
48 |
internal oscillator might be at the end of the bell curve but within |
49 |
manufacturer tolerance, which isn't enough to produce a USB signal |
50 |
close enough to the specified frequency. Expect the seller to pay for |
51 |
return shipping. |
52 |
|
53 |
2) You can calibrate the oscillator using instructions in this |
54 |
application note: |
55 |
http://www.atmel.com/Images/Atmel-2555-Internal-RC-Oscillator-Calibration-for-tinyAVR-and-megaAVR-Devices_ApplicationNote_AVR053.pdf. |
56 |
This process still might not get you close enough. |
57 |
|
58 |
3) Add a crystal oscillator to the ATtiny85 and change its fuses to |
59 |
use the oscillator. You will need to recompile the firmware if the |
60 |
crystal is a different frequency from the internal oscillator. |
61 |
|
62 |
It might work on your phone and not your desktop because of |
63 |
differences in the USB hardware (your phone's serial decoder in the |
64 |
USB hardware performs clock recovery but your PC does not) or because |
65 |
there are multiple things on a USB hub in your PC and the ATtiny85 is |
66 |
less accurate than those already present devices. Admittedly I'm |
67 |
surprised it gets most of the way to registering as a device and then |
68 |
fails, but I don't think the problem is with the drivers or your |
69 |
kernel. It's also not very likely to be a problem with the USB code |
70 |
unless it was reimplemented for DigiStump's product (check against |
71 |
these libraries |
72 |
http://www.fourwalledcubicle.com/files/LUFA/Doc/120219/html/_page__alternative_stacks.html). |
73 |
|
74 |
R0b0t1. |