REV Hub firmware updater in v4 is very prone to hang

[Windwoes]

Yesterday I updated 3 REV Hubs to the 1.8.2 firmware using SDK v4.0, and it did not go very well.

The first Hub updated fine. When updating the second Hub, the firmware transfer hung at 3%. I gave it a full minute, and then pulled the power and USB cords. The Hub was bricked, although thankfully since v4 can detect bricked Hubs, I was able to flash again without issue. When updating the third Hub, the app hung as soon as I hit the update button. I once again gave it a full minute and then pulled the power and USB. The Hub was not bricked this time (presumably since the firmware transfer hadn't even started), and trying the update again worked fine.

So, while it's great that v4 can reflash a bricked Hub, it is not really great that it hangs 50% of the time....

[rgatkinson]

Do you happen to have a log from this encounter? FWIW, success rates seem to vary widely, and we'd (of course) like to understand the root cause better than we do.

[Windwoes]

@rgatkinson

Here's the log for the second Hub failure (the one that bricked): https://gist.github.com/FROGbots-4634/e1ee970bbd6f4dc5debe3042cb6f466a

And here's the log for the third Hub failure (immediate hang, no brick): https://gist.github.com/FROGbots-4634/185e435cdd58dd0f0ad6997dbe7a441b

[Windwoes]

Also, I'd like to make a suggestion: first send the Hub an MD5sum of the firmware binary, and then when you send the firmware to the Hub, have the Hub hold the entire file in memory and verify the checksum before it flashes it to the EEPROM. That should prevent bricking.

[rgatkinson]

Thanks for the logs; we'll have a look.

The FW update protocol isn't something we control; it's defined by Texas Instruments. Also: the part doesn't actually have enough memory space to defer updating the EEPROM until it receives an entire new image; rather, it's forced to update on the fly. Thus, while your checksum suggestion is a good one, it's not something that can be implemented.

[rgatkinson]

Those logs are quite helpful, actually; thank you! They implicate a larger bug we've seen in entirely different contexts (e.g. very long running opmodes), wherein a device / EH spontaneously detaches with exactly the same symptoms. We suspect that it's a very low-level Android issue (there have been others in Android USB over the years), but have yet to track it down. I'd very much like to catch it in the act with a HW USB sniffer attached, and maybe this will help us do that.

For the record, what RC device were you using?

[Windwoes]

@rgatkinson

For the record, what RC device were you using?

Nexus 5

[JBYoshi]

Our expansion hub got stuck while updating as well. I remember it was at 58%, and then timed out. I couldn't try again because the USB cable broke (I checked the cable against a different expansion hub which hadn't been updated, and the cable failed there as well).

[Windwoes]

@JBYoshi perhaps a failing USB cable was the cause of the hang for you then?

[JBYoshi]

That's quite likely. We have a REV Expansion Hub USB mount on the way, and I will try updating with the cable included with that once it comes in.

[JBYoshi]

Update: We successfully updated both of our expansion hubs at our meeting today.

I did encounter a problem a few times where the app wasn't detecting the expansion hubs. I saw an error in the logs saying something about being unable to lock access to the USB. Based on my programming experience (the synchronized keyword in particular), I deduced that the app had already claimed access to the USB device and wasn't properly releasing it. I hit "restart robot" and then killed and reopened the app, and the hubs showed up.

I did get a hang while updating one of the hubs, but after restarting the robot and the app, that hub updated as well.

[Windwoes]

Probably fixed in v5.5 (update speed reduced)