Re: [gentoo-user] USB device (ATtiny86 w. mcronucleus bootloader) not recognized ?

Hi,


On 08/06 07:04, R0b0t1 wrote:
> On Sun, Aug 6, 2017 at 11:50 AM,  <tuxic@××××××.de> wrote:
> > When I plug in such a little board into my PC, demesg
> > reports:
> > [ 1429.834140] usb 7-4: new low-speed USB device number 15 using ohci-pci
> > [ 1429.965142] usb 7-4: device descriptor read/64, error -62
> > [ 1430.203151] usb 7-4: device descriptor read/64, error -62
> > [ 1430.438161] usb 7-4: new low-speed USB device number 16 using ohci-pci
> > [ 1430.569151] usb 7-4: device descriptor read/64, error -62
> > [ 1430.803174] usb 7-4: device descriptor read/64, error -62
> > [ 1431.038184] usb 7-4: new low-speed USB device number 17 using ohci-pci
> > [ 1431.456157] usb 7-4: device not accepting address 17, error -62
> > [ 1431.582204] usb 7-4: new low-speed USB device number 18 using ohci-pci
> > [ 1432.000209] usb 7-4: device not accepting address 18, error -62
> > [ 1432.000244] usb usb7-port4: unable to enumerate USB device
> >
>
> >
> > My first thought was: The micronucleus bootloaed is missing or
> > is defective...
> >
> > But plugging in the board into my Android tablet (the tablet runs
> > Lollipop and is nothing special at all beside being rooted) via
> > an OTG cable and using lsusb after that, it shows
> > Bus 001 Device 003 ID 16d0:0753 MCS Digistump DigiSpark
> >
>
> What the dmesg output is saying is that your USB hardware has reported
> a communication error to the driver. It is my guess that the ATtiny85
> is not meeting the timing requirements for USB.
 
The above is the only part of the dmesg log regarding this usb
"device"...

If I plug it into a usb-port, it "works"... (read: will be recognized
according to dmesg, but still the udev rules dont get triggered, so 
I still get nothing under /dev/...


> Looking at the board there does not seem to be a crystal oscillator
> which most people would consider necessary for doing USB
> communication. This is an oversight on DigiStump's part and it is very
> likely you will not be able to fix the communication issues. You
> should contact them and tell them that your computer will not
> recognize their device and that you suspect it is because the clock is
> too inaccurate.

...the board is a thumbnail thing:
http://digistump.com/products/1

No crystal. It is not an original digistum and had cost me less than 1
EUR...so not such a painful loss...


> >
> > What can I do to make this Digispark being correctly recognized?
> >
> > Thank you VERY much for any help in advance!
> >
>
> Three things:
>
> 1) Return the one you bought and get a new one. The ATtiny85's
> internal oscillator might be at the end of the bell curve but within
> manufacturer tolerance, which isn't enough to produce a USB signal
> close enough to the specified frequency. Expect the seller to pay for
> return shipping.

  Returning the board does cost more than the board and I haven't
  any hope that this will change anything: I have six of them and none
  works. "The design can be improved..." to be friendly.


> 2) You can calibrate the oscillator using instructions in this
> application note:
> http://www.atmel.com/Images/Atmel-2555-Internal-RC-Oscillator-Calibration-for-tinyAVR-and-megaAVR-Devices_ApplicationNote_AVR053.pdf.
> This process still might not get you close enough.

  I have no oscilloscope nor a frequency counter. 
  That is above my financial possibilities...

> 3) Add a crystal oscillator to the ATtiny85 and change its fuses to
> use the oscillator. You will need to recompile the firmware if the
> crystal is a different frequency from the internal oscillator.

  There is not enough space on the board.

> It might work on your phone and not your desktop because of
> differences in the USB hardware (your phone's serial decoder in the
> USB hardware performs clock recovery but your PC does not) or because
> there are multiple things on a USB hub in your PC and the ATtiny85 is
> less accurate than those already present devices. Admittedly I'm
> surprised it gets most of the way to registering as a device and then
> fails, but I don't think the problem is with the drivers or your
> kernel. It's also not very likely to be a problem with the USB code
> unless it was reimplemented for DigiStump's product (check against
> these libraries
> http://www.fourwalledcubicle.com/files/LUFA/Doc/120219/html/_page__alternative_stacks.html).
>
> R0b0t1.
>