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

[R0b0t1]

On Mon, Aug 7, 2017 at 4:29 AM, Stefan Mark <mark@××××××××.de> wrote:
> On Sun, 6 Aug 2017 19:04:09 -0500
> R0b0t1 <r030t1@×××××.com> 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.
>>
>> 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.
>>
>> >
>> > 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.
>>
>> 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.
>>
>> 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.
>>
>> 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.
> USB uses a variant of non-return-to-zero for clock synchronisation,
> that should™ take care of timing issues.
> Actually, using microcontrollers without crystal for soft-usb is fairly
> common (i have a bunch myself). As far as i understand (but im no
> expert), trouble usually arises more from the improvised level shifters
> than timing issues.
> Anyway, i neither think there is a driver problem, i had a fair bit of
> the messages myself, usually fixed by fixing the level shifter.

An NRZ signal is part of the reason USB is so finicky. With USB the
clock has to be within some tolerance of the bus speed (the
justification being that there are multiple devices on the bus that
need to read the bus at all times) and this is fairly inflexible. With
other protocols, like most USART transceivers, the hardware can
recover the sender's frequency and compensate if it is wrong.

The level shifters might be causing timing problems, seeing as some
hardware does recognize the ATtiny85 and the levels might be right. It
seems less likely that a voltage difference would be OK between two
pieces of hardware to me.

There's a lot of old advice related to microcontrollers that says you
need to use crystals when you actually don't with modern parts, so I
think it reasonable that your advice will work. I hope Meino gets back
to us.