I went to update my 2 Reach modules to 2.10.0 First one went fine, second one I have a hiccup I need help with.
Steps taken.
Power reach module indoors near wifi router. It connects to my wifi network.
Locate Reach’s IP and connect via web browser.
Update notice at top of page in Reachview. Tap Update.
An updater page is launched and a checklist is dynamically checked. At the end I click on update. After a series of downloads, there is a notice to reboot.
I reboot and again Reach connects to wifi network and after checking, it is confirmed that the FW is now updated.
I did the above with the first unit and it went exactly like my list. On the second unit, the updater page opened, the checklist was completed and I clicked on update. The series of downloads began and during that process, the Reach lost connection with the network and seemed to reboot. (sceenshot of where it was when connection was lost below)
It was not moved or touched during this process. It is now displaying a solid white LED and rebooting returns to the same solid white LED state. There is no Hot Spot detected from the module. It seems suspicious but may just be a coincidence that the disconnect occurred when it was in the process of dealing with a “wifi reconnect” module as seen in the screenshot.
Typically, loosing connection during a FW update on any device is not a good thing.
Advise on what to do now would be appreciated. Is this the point when re-flashing is required?
Thanks for the detailed report! Unfortunately, Reach update process requires a stable Internet connection. The solution for your case is indeed reflashing.
We will dig through our update subsystem to see what can be done to make issues like this go away.
I first tried installing the driver and then using the terminal method on a win.10 with powershell
I received the following:
PS C:\Users\Pitman\Desktop\ReachImage_v2.9> .\flashall.bat
Using U-boot target: edison-blankrndis
Now waiting for dfu device 8087:0a99
Please plug and reboot the board
'dfu-util' is not recognized as an internal or external command,
operable program or batch file.
I plugged in the board and there was no change or interaction. I tried this twice with the same result.
I then moved on to the gui method using the workaround. It flashed the board successfully, but upon reboot, I got a solid red LED and of course no connection.
I re-tried the gui method and it flashed successfully and a reboot put me back in business. I then went through the same update steps as before and this time the board was successfully updated to 2.10.0
Definitely not a silky smooth update but in the end successful.
Seems like newer Windows versions do not provide dfu-util we use for flashing. You have to install the tool to use the terminal method too now. Thanks for the tip, we’ll update the docs accordingly.
