Thanks for doing this work and sharing your results. I really prefer not to push workarounds for problems that are not fully understood. Specifically I would prefer workarounds only once it is decided that a problem is out of our control to fix proper. What might be helpful is to open a bug (on the GitHub issue tracker) specifying the observed problem and procedure for reproducing it.
On Sun, Feb 1, 2015 at 6:59 AM, Paul McMahon <[email protected]> wrote: > OK, I've done quite a bit more debugging on this. > I first tried re-issuing the checkInterface command, and found that this > did not recover the IOIO state. Neither did issuing a SoftReset(). > But HardReset() does recover the link. It causes my app to get > re-launched, but that's an acceptable tradeoff for not being able to > connect to IOIO at all. > I'm attaching the patch file here. Changes are to IOIOImpl.java and > IncomingState.java > Some explanation: > I found that when stuck in this state, it's the call to > waitForInterfaceSupport that is hung, waiting on the state to change to > Connected. So I now ensure I'm already in the Connected state before > calling that method, so I know it won't hang. I issue the checkInterface > in a loop ,checking for the state change manually before allowing it to > proceed. The check is via a new method in IncomingState.java called > isEstablished(). I'm waiting 100ms after issuing HardReset, to give the > system time to recover. > > Also, I noticed some Null Pointer Exceptions inside handleSoftReset() when > I was doing rapid power cycling. I now have pointer checks at each step of > that routine. > > I'm not sure if you want to accept this change, but it's a decent > workaround for me, so I thought I'd share this update. If you think it's > worthwhile, then we should probably limit the number of retry attempts, and > throw an exception if the limit is reached. In my experience, recovery is > needed once per 10 or 20 cycles, and one retry is all that's ever needed. > > On Sunday, February 1, 2015 at 2:04:24 AM UTC-5, Ytai wrote: >> >> This is not a valid protocol. One thing that might explain this is that >> the IOIO got some corrupt data, which caused it to close the connection and >> immediately re-open it. >> The leading 0x01 you're seeing is part of a meta protocol used only in >> AOA mode that works around the fact that AOA doesn't have the notion of >> opening and closing a connection to the accessory. >> Since I don't believe it is very likely that data actually got >> *corrupted* at the USB level, it is more likely that a byte got >> discarded somewhere along the AOA stack, be it in the IOIO software / >> firmware or in the Android protocol stack. >> If you want to dig deeper, you can try building the IOIO firmware with >> logging enabled, which would give you some diagnostics over a serial (UART) >> connection on one of the pins. This will allow you to know what things look >> like from the IOIO side. >> >> On Sat, Jan 31, 2015 at 6:01 PM, Paul McMahon <[email protected]> >> wrote: >> >>> Ytai, >>> I'm attaching 2 files here, a good example and bad one. Each log shows >>> the accessory connection processing, as well as the bytes passing back and >>> forth across the interface. >>> >>> In both cases, I see the IOIO wake up with the "establish connection" >>> stream, which includes all the version numbers. >>> Then the phone sends the CHECK_INTERFACE code 0x02, and the IOIO0003 >>> string. In the passing case, IOIO responds with 0x2 0x1, indicating a >>> version match, and we're off and running. >>> In the bad case, IOIO responds with 0x1 and sends the initial string all >>> over again. >>> >>> I haven't looked at the firmware code, but maybe you can tell me what >>> that response is indicating? >>> >>> thanks. >>> >>> >>> -- > You received this message because you are subscribed to the Google Groups > "ioio-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/ioio-users. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "ioio-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/ioio-users. For more options, visit https://groups.google.com/d/optout.
