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

[Stefan Mark]

On Mon, 7 Aug 2017 12:10:30 -0500
R0b0t1 <r030t1@×××××.com> wrote:

> On Mon, Aug 7, 2017 at 11:29 AM, Stefan Mark <mark@××××××××.de> wrote:
> > 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.
>
> NRZ just means that every time period of your signal indicates a
> value. You don't spend any time resting between bits. Because you
> don't spend any time resting and every time period contains a value,
> you need to have an accurate clock to read the data from the signal.
Yes, but USB uses a variant ("Non-return-to-zero space") where every n
Bits (6 for USB) a Zero (Level change) is inserted to synchronize
clocks. At least thats what the Wikipedia says. 

> I can usually get a crystalless UART to work at room temperature in a
> habitable room. That isn't really enough for me to assume it would
> work anywhere else. I think you are seeing problems with your serial
> communication because you are doing more of it and it contains no
> built in error correction. I expect VUSB retries failed packets, and
> USB packets are themselves very short.
Might just be that the connection is not used most of the time. Maybe i
can even fix it if i send some data every few seconds. Damn, never
thought about it that way oO

> >> 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 :)
>
> As above, this isn't really enough to assume that this works in
> general. Circuits usually work at room temperature. USB, even low
> speed USB, is a very technically demanding specification to implement
> because of the timing requirements (the specification being nearly
> incomprehensible is a separate matter). There's very little reason you
> can't theoretically make an RC network accurate enough to do USB
> communication, but typically, cheap microcontrollers are made on
> cheaper, larger, and less accurate IC processes that have looser
> tolerances.
>
No, didnt meant to. But it usually works under "common" circumstances.
Wouldnt recommend it for production use :D