USB reconnect issue with app version IOIO0506

[kedder]

I have the following problem with my IOIO-OTG device: when I disconnect usb cable from android device and then reconnect it immediately, IOIO device fails to connect/be recognized by IOIO application software.

I am providing an external power to IOIO device (12v from external battery), so when I reconnect android device, IOIO is not rebooted. If I reboot IOIO, android device can see it again. I am convinced that the problem is on IOIO side, because once IOIO is in this "broken" state, other android devices cannot detect it either. I have two applications I'm testing with: "XCsoar" and "Hello IOIO". Both show the same symptoms.

Apparently, the latest IOIO0506 version of the firmware is affected more then older versions. I tested with IOIO0330 and IOIO0400 and they work fine most of the time (I was able to put IOIO in this broken state by repeatedly connecting and disconnecting device on these old versions too, but it is much harder to do: IOIO0506 requires single disconnect to reproduce the issue). "Hello IOIO" doesn't work with older firmware versions, but XCsoar works fine.

Is there anything I can do to debug this?

For the reference: IOIODude output:

$ ./ioiodude --port=/dev/IOIO0 versions
IOIO Application detected.

Hardware version: SPRK0020
Bootloader version: IOIO0400
Application version: IOIO0506

"Hello IOIO" Uses IOIOLib 5.07.

Android devices are "Samsung Galaxy Tab S2" and "LG G4", both with USB debugging switched off.

[ytai]

I've done many of these tests in the past and got to a very reliable state in handling connection / disconnection. With OpenAccessory, there have been some issues that were impossible to fix because how Android behaves. However, this is the first time I'm seeing evidence that indicates there might be something going on on the firmware side as well. I'm wondering whether something might have changed in later versions of Android that can somehow cause the IOIO to get into a funny state. I don't know how comfortable you are with the firmware side of things. How I would typically debug this is by either attaching a debugger and trying to see what state the IOIO is in (as far as the USB stack) when it is in the broken state or otherwise enable logging on the firmware and try to reason about the state from the printed info. The latter has the drawback of messing with the timing, so you might actually not be able to repro this way. The former sometimes required some gymnastics to get the debugger going.

[kedder]

@ytai, I'm a software dev, so I can get myself comfortable with anything that doesn't require me to solder/unsolder stuff from the IOIO board or have some special hardware. But I need some directions, since I'm not familiar with protocols.

Is there something specific I can check/verify when I get IOIO in apparently "broken" state? Is there any pointers on how do I enable firware logging and how can I access these logs?

[kedder]

Closing this, as it is not causing excessive problems in practice, even though happens sometimes.

[WaterReNu]

Kedder, although it doesnt seem to be an issue for you, it is a significant issue with faster tablets / android 6 as when compared to Android 4 / slower tablets. We are using ioio in production as part of a control and management system.

In android 6, the main issue is not connecting after a tablet reboot. Something goes wrong on the ioio side, and will not reconnect without being powered down first. This is a critical problem for a 24 / 7 system.

Please let me know if you happened across a firmware fix that automatically reboots the ioio device upon no usb traffic (a kludge fix - but we are urgently trying to resolve this.

[kedder]

@WaterReNu I opened the issue 3 years ago and it didn't look like it had any movement or gathered any more details since then, so I decided to close it to indicate I don't really care about it that much anymore.

That said, feel free to re-open it if you feel the issue is still important to fix.