Betaflight-configurator: REVO: USB DFU flashing hangs since #1227?

[AirBreak69]

Since mikeller merged #1227, flashing via DFU mode seems to be broken. This happens:

• Starting flash operation on a (good old) naked REVO FC brings it to DFU mode. DFU mode is recognized by the configrator.
• But the flashing does not continue.
• Trying to stop the flashing by clicking the update button again leads this message: " You can't do this right now, please wait for current operation to finish ..."
• The FC remains in DFU mode. Only power cycling brings it back to normal operation.

Please be carefull, because I have a "very special" setup: Unfortunately no updated windows configurators are available. So I use a installed 10.4 windows package and cherry pick (manually merge) new files from the code base into the configurators folders.
This worked fine for the last months with numerous firmware/configurator versions and a handfull of FC types. But the last merge broke the DFU flashing. #1227 added DFU device types and may have touched a delicate part. This is why I like to address this to @jflyper ...

All that may be my fault but the changes done in #1227 look like a possible trap (without knowing what the bug may be).

[mikeller]

@AirBreak69: Instead of cherry-picking, try building from latest on master, and see if this fixes it - it's well possible that these changes will break when built against an older version of the NW.js toolkit.

[AirBreak69]

@mikeller: Was a lot of work to get it run. Had to deal with path extensions and overcome problems like this:
https://github.com/gulpjs/gulp/issues/2246
Finally I got the build running and started the fresh configurator.
But I have to disappoint you - the problem still exists!
Made a cross check against https://github.com/betaflight/betaflight-configurator/releases/download/10.4.0/betaflight-configurator-installer_10.4.0_win32.exe to discover potential PC problems: The old offcial version can flash the FC.

For others, who want to do the same:

• installed https://nodejs.org/dist/v11.2.0/node-v11.2.0-x86.msi
• opened a CMD-shell in the "_project folder_" (a fresh copy of https://github.com/betaflight/betaflight-configurator/archive/master.zip)
• extended the windows search path by set PATH=%PATH%;C:\Program Files\Git\cmd;c:\"_project folder_"node_modules.bin to get the dependencies loaded and to get gulp.cmd found
• ran npm install
• ran npm start
• tried gulp release --win32 but it ends in an "internalbinding" error. I had to install npm install [email protected]
• followed the hints after installing [email protected] and ran npm audit fix
• now gulp release --win32 runs through but throws some "depreciated warnings". I could not solve them.

[mikeller]

@AirBreak69: Interesting. I never tested the change on Windows, but I know it works on linux and assume it works on Mac (@jflyper uses Mac). What version of Windows are you using?

I'll try to replicate on Windows later on.

[AirBreak69]

@mikeller: I use - like most of the helpless Microsoft addicts - latest and greatest Win10, x64, October build 1809.

[mikeller]

@AirBreak69: Sorry to say, but I was not able to reproduce your problem, npm start runs configurator and flashes firmware just fine for me on latest master under Windows.

gulp release --win32 but it ends in an "internalbinding" error. I had to install npm install [email protected]

This is fishy - gulp release --win32 runs just fine for me under Windows. Could it be that there is a problem with the node modules and NW toolkit artefacts in your repository directory? Try cloning into a fresh directory, then running npm install and gulp release --win32 and see if that works.

After that, can you run npm start, open a debug console, and see what error is thrown when trying to flash firmware?

P.S.: The deprecation warnings are normal - welcome to the brave new world of npm package management where we try to build house sized applications out of lego bricks that are maintained by volunteers.

[AirBreak69]

@mikeller: Sorry to read this. I did some more tests, but the problems are still there. Looks a bit "specific to my computer".

• is not FC specific: REVO and DYSF4PRO behave the same
• is configurator version specific:
  Release 1.0.4.0 is OK
  Early release 1.0.5.0 from mid August 18 with cherry picked updates including #1227 is not OK (was OK before this particular PR, but I cannot wind back to double check it)
  New local NW.js build including updates up to PR 1236 is not OK .
  A second new local NW.js build from an empty clone was not OK, too. All NW/gulp stuff was renewed from the scratch to the latest versions. Needed the following commands npm install, npm audit fix, npm install [email protected], gulp release --win32.
  [Edit]
  A third new local NW.js build from an empty clone was not OK, too. All NW/gulp stuff was renewed to 11.3 NW toolkit in x64 flavor. Needed the following commands npm install, npm audit fix, npm install [email protected], gulp release --win64.
  [Edit2]
• tried the latest build on two additional and completely different computers: identical behaviour.
  _This shifts the responsibility back to PR 1227._
  [Edit3]
• if flash attempt hangs and the FC still is in DFU mode: Exit the configurator and restart it. Now a new flash attempt starts over.

I think we should leave this open for a while. Just to see if other users face the same problem.
The "[email protected]" include seems to be needed as a workaround for the 11.x NW toolkit.

[AirBreak69]

@mikeller: Thanks! #1241 fixes it.

[mikeller]

@AirBreak69: The interesting thing is that this didn't actually break flashing for me - it still worked but while looking at the console log as part of investigating a different problem I saw that flashing threw an unexpected exception, looked into the code and found / fixed this obvious bug (obvious if you looked at it).

[AirBreak69]

@mikeller: obvious for you...
To be honest: it is still not really flawless. Flashing runs through now, but you cannot connect right after flashing. Connect does only work after flashing if you restart the configurator.