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

[Stefan Mark]

On Mon, 7 Aug 2017 08:48:50 -0500
R0b0t1 <r030t1@×××××.com> wrote:

> 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.
As far as i had understand it, the idea of NRZ is to compensate minor
drifts between the two clocks. If not that, what its then for?
Strangely, i had often trouble with uart when i dont used crystal. The
connection always failed after a while. Never had that with vusb.

> 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.
>
I have build (or helped building) at least 20 littlewires
(attiny85 based, no crystal). They work :)