Tiny-USB hangs on host reboot

[BeetleX99]

Hi,
i2c-tiny-usb (main.hex on digispark) is fine with debian host.

But if the host is rebooting, the tiny doesn´t respond to the usb registering process. After a system reboot just pulling and replugging the hardware module re-enables the module again.

Any advice for fixing? I am not familiar with the USB state machines...

[PizzaProgram]

I have just realized:
This is TRUE!

After reboot > device is not recognized. Only manual unplugging / re-plugging helps.

So basically this makes the whole thing useless, unless there's a trick we don't know about?

[BeetleX99]

I tried something on Linux level, but didn´t succeed. I am not the expert so far.
As the original project was transferred to Digi/Ada, maybe the hangup is caused by this?
Anyone out there, being able to check this? Till?

[BeetleX99]

Sorry, closed by mistake!

[PizzaProgram]

Since the author isn't answering, I'm forced to ask:

• Are there any other Firmwares doing the same as this one (without bugs like this) ?

[zgyarmati]

I've looked into this briefly. It seems that this only happen with the digispark port of the i2c-tiny-usb fimware. Digispark uses an USB bootloader micronucleus, and I suppose (but I didn't really debug this), that the USB bootloader causes the issue. I think if you flash the original (not Digispark/micronucleus based) fw on the Digispark module's attiny85, than the issue will disappear, without getting/building new hardware.

[harbaum]

What exactly do you think is the problem? Are other digispark based projects also affected by this?

[zgyarmati]

Oddly it turned out that with my Digispark (likely a clone, i don't even remember where i bought it) i can't reproduce the issue, neither with reboot nor with switching off and back on my computer, by using the main.hex available in the digispark dir. One variable could be the micronucleus bootloader version. @BeetleX99 , @PizzaProgram, could you please check what bootloader version do you have? It's written when the .hex is flashed with micronucleus as:

Device has firmware version 1.11
Available space for user applications: 6330 bytes
Suggested sleep time between sending pages: 8ms
Whole page count: 99 page size: 64
Erase function sleep duration: 792ms

[PizzaProgram]

I have used a special fork of micronucleus, that is compatible with WinUSB driver, because it was impossible to flash the device with the "normal one".
(Unknown device keeps popping up only for 2 sec in device manager, so no chance to install a driver.
Zadig.exe is refreshing every 3 sec too.)

> Please plug in the device...
> Press CTRL+C to terminate the program.
> Device found!
> Device has firmware version 1.6
> Available space for user application: 6012 bytes
> Suggested sleep time between sending pages: 8ms
> Whole page count: 94, page size: 64
> Erase function sleep duration: 752ms
> Erasing flash memory...
..........
> Writing flash memory...
.....................................................................
> Starting the user application...
> Micronucleus done. Thank you!````

[PizzaProgram]

libwdi:debug [wdi_create_list] Hardware ID: USB\VID_0403&PID_C631&REV_0201
libwdi:debug [wdi_create_list] Compatible ID: USB\Class_00&SubClass_00&Prot_00
libwdi:debug [wdi_create_list] Driverless USB device (2): USB\VID_0403&PID_C631\0070
libwdi:debug [wdi_create_list] Device description: 'i2c-tiny-usb'

[zgyarmati]

I flashed the 1.6 version of the Micronucleus bootloader FW from here: https://github.com/mariusgreuel/micronucleus/tree/v1.06/firmware/releases (the file "micronucleus-1.06.hex") and on the top of that I flashed the i2c-tiny-usb main.hex from this repo. I can't reproduce the issue with rebooting on my Linux box... I see that your OS is Windows, but unfortunately i don't have the means to debug this under Windows.

[PizzaProgram]

hmmm.... now I don't understand:

1. Is there 2 different .hex file I need to flash? (1 for the boot loader + 1 for the I2C>USB?)
2. How is 1.6 version = 1.06 ?
3. How do I flash a boot loader anyway? Is it possible with Arduino IDE?
4. Isn't it possible to do everything from Arduino IDE software anyway?

[PizzaProgram]

I can't reproduce the issue with rebooting on my Linux box...

What kind of "box" is that? A Raspberry Pi?
Is that box unpowering for a moment the USB port while rebooting?
(Because the RPi 4 does NOT >> and that's causing the problem)

[BeetleX99]

Great News!
I did some testing at CubieTruck and Raspi in parallel, and now I just found the culprit!
If the Tiny runs behind an usb-hub, it will fail in rebooting,
connected directly to the CubieTruck the Tiny is activated after each reboot!!!

[zgyarmati]

@BeetleX99, thx for sharing this observation! The hub has an external power supply, or host-powered?

[PizzaProgram]

@BeetleX99 I guess you have an external power at your USB hub. Or maybe a bigger capacitor (condenser) built-in that "holds" the power for a moment while your mainboard is rebooting.
Which gives a great idea:

The developers could use an external powered USB HUB to simulate and debug the problem too!

[PizzaProgram]

I've just quickly looked at the kerner code but I don't find any "keepalive timer", that triggers a re-inic sequence of the device if that signal is lost. So this is maybe an architectural problem of the whole code design?

IMHO it's much more difficult to detect a signal loss, if not BOTH parties of the communication are keeping track of each other from time to time. (Maybe once every 1 sec? )

[BeetleX99]

My hub doesn´t have an externel power supply.

[Gemba]

FWIW, you may try this patch.

[PizzaProgram]

Sounds great! 👍

Sadly this is a bit too complicated for me how enable this patch on my RPi4.
I guess a new linux Buster kernel release / upgrade will come out soon, and the driver will be auto-upgraded?

... about these lines starting from 14:

+    i = 0;
+    while (--i) { /* fake USB disconnect for > 250 ms */
+        _delay_ms(30);
     }

How can this run for 250ms if i=0 ?

[Gemba]

Maybe it can/will be fixed in a future kernel/firmware (if it can be attributed to be a kernel/firmware issue). I did not update to the latest development there.

The -- is the trick here together with the type of i. -- is an decrement operator which decreases the value of i before it gets evaluated in the while condition. As i is a uchar/byte it will be 255 at the first evalutaion of while().

[PizzaProgram]

Maybe I have too low programming knowledge after 35+ years of learning, but this while cycle does not seem to be right.
If you say this should run for 250ms, than "--i overflow" start at 255 x 30ms delay = 7650ms.

How about a simple, clear code, that everyone can understand and nobody thinks it's a bug?

i = 0;
while (i < 12) { /* fake USB disconnect for > 250 ms */
  ++i;  _delay_ms(25);
}

That will run for 250ms, not 7650, or cause any byte-overflow ... (i <> 12) or (i != 12) is fine too, I just don't know the exact syntax.

[PizzaProgram]

I did not update to the latest development there...

Why not ?

[o2bshane]

I too have experience a digispark freezing after a reboot of the host computer. This happens with every micronucleus firmware except the default. It seems we need the digispark to enter bootloader mode to re-initalize the USB connection after the host reboots otherwise it freezes. I've tried using a WDT to reset the digispark and the USB connection but again with a modified micronucleus ( like one that only enters the bootloader on external reset) it freezes without the bootloader resting the USB connection.