Betaflight-configurator: REVO. USB DFU flashing hangs with "Full Chip Erase" enabled.

[AndersHoglund]

Flashing RTFQ Revo Acro via USB-DFU hangs in "Erasing...."-state. No progress bar.
I have been forced to use RFC 1.3.5 flasher, works fine.

Tried BFC 1.7.1 from the store and also a fairly new from github (9d2a3a3d0), same same.
On Win10 Annniversery update and Chrome: 52.0.2743.116

Flashing SPRF3 works fine. Only tried "No reboot seq.." with bootpads shorted though.

[borisbstyle]

Are you using correct Zadig drivers?

I believe there are few different to choose and only one of those works for
me on other boards

[AndersHoglund]

Well, same driver used by RFC and that works OK. WinUSB (v6.1.7600.16385)
Will test on Ubuntu, stay tuned.

[AndersHoglund]

Almost the same on Ubuntu. Just sits there "Erase"-ing with no progressbar, but then when I was about to give up; "Flashing", with a progressbar. And then "Verifying" and Sucess. Done.
On Windows I have been waiting at least 5min for "Erase"-phase to finish, but no go. Will leave it there and see what happens in the next few hours. Might just be slow erase.
But progressbar missing is still a flaw.

[AndersHoglund]

Noticed in the log that the DFU USB is opened when I hit "Flash Firmware", then at some (random ?) time later it silently closes USB. GUI only says "Erasing..." the whole time. In this sample I hit "Flash"-button three times, last has not closed/finished yet (6min later).

2016-08-09 @ 19:02:27 -- Running - OS: Windows, Chrome: 52.0.2743.116, Configurator: 1.7.1
2016-08-09 @ 19:02:53 -- USB device successfully opened with ID: 24
2016-08-09 @ 19:02:53 -- Detected device with total flash size 1024 kiB
2016-08-09 @ 19:02:58 -- USB device successfully closed
2016-08-09 @ 19:03:05 -- USB device successfully opened with ID: 25
2016-08-09 @ 19:03:08 -- Detected device with total flash size 1024 kiB
2016-08-09 @ 19:03:13 -- USB device successfully closed
2016-08-09 @ 19:04:31 -- USB device successfully opened with ID: 26

Also, "Flash on connect" does not work. Have to manually hit the Flash-button.

[nathantsoi]

fyi. this happens to me sometimes on my mac, usually after doing a save
operation on the fc w/o rebooting the fc. it totally destroys the serial
port held by chrome and i have to hard reboot my computer as for some
reason, chrome won't nicely release the resource.

On Tue, Aug 9, 2016 at 10:12 AM Anders Höglund [email protected]
wrote:

Noticed in the log that the DFU USB is opened when I hit "Flash Firmware",
then at some (random ?) time later it silently closes USB. GUI only says
"Erasing..." the whole time. In this sample I hit "Flash"-button three
times, last has not closed/finished yet (6min later).

2016-08-09 @ 19:02:27 -- Running - OS: Windows, Chrome: 52.0.2743.116, Configurator: 1.7.1
2016-08-09 @ 19:02:53 -- USB device successfully opened with ID: 24
2016-08-09 @ 19:02:53 -- Detected device with total flash size 1024 kiB
2016-08-09 @ 19:02:58 -- USB device successfully closed
2016-08-09 @ 19:03:05 -- USB device successfully opened with ID: 25
2016-08-09 @ 19:03:08 -- Detected device with total flash size 1024 kiB
2016-08-09 @ 19:03:13 -- USB device successfully closed
2016-08-09 @ 19:04:31 -- USB device successfully opened with ID: 26

Also, "Flash on connect" does not work. Have to manually hit the
Flash-button.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/betaflight/betaflight-configurator/issues/200#issuecomment-238622640,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAYZmomsHY8UT--Qpa_2dyEXYBf7Bc0vks5qeLUQgaJpZM4JgPh_
.

[borisbstyle]

Yeah I always do fresh reconnect some targets before flashing

[AndersHoglund]

Only happens with "Full Chip Erase" enabled, it seems. And I almost always use that....
(RFC does not have that option at all anymore....)

[borisbstyle]

I was never able to do that on VCP targets actually.
I always flash those without erase

[Tomcatt]

What if he's having baudrate issues? Too fast? Too slow?

I'll have to research it but with command line you can add a progress bar to it.

[kaefert]

I see an issue similar to this but for me I get "open", "detect" and "close" all within the same second of pressing the "Flash Firmware" button. Afterwards the status line will read "Erasing ..." forever.

2016-10-02 @ 17:00:39 -- USB device successfully opened with ID: 1
2016-10-02 @ 17:00:39 -- Detected device with total flash size 256 kiB
2016-10-02 @ 17:00:39 -- USB device successfully closed

The board I'm trying to flash is this one: https://www.aliexpress.com/item/SP-RACING-F3-EVO-Brush-Flight-Control-Board-For-90mm-120mm-125-mm-FPV-Mini-Micro/32712751945.html
And I'm not sure if this is a problem but it seems strange that the hex file of the firmware is 421kb in size and this output tells me that my flightcontroller has only 256kb available. Might this be the problem why I cannot flash a new firmware?

[nathantsoi]

Something similar happened to me last night and I just hit the flash button
again, without changing pages or reloading firmware and it worked. Does
that work for you?

On Sun, Oct 2, 2016, 8:09 AM Thomas [email protected] wrote:

I see an issue similar to this but for me I get "open", "detect" and
"close" all within the same second of pressing the "Flash Firmware" button.
Afterwards the status line will read "Erasing ..." forever.

2016-10-02 @ 17:00:39 -- USB device successfully opened with ID: 1
2016-10-02 @ 17:00:39 -- Detected device with total flash size 256 kiB
2016-10-02 @ 17:00:39 -- USB device successfully closed

The board I'm trying to flash is this one:
https://www.aliexpress.com/item/SP-RACING-F3-EVO-Brush-Flight-Control-Board-For-90mm-120mm-125-mm-FPV-Mini-Micro/32712751945.html
And I'm not sure if this is a problem but it seems strange that the hex
file of the firmware is 421kb in size and this output tells me that my
flightcontroller has only 256kb available. Might this be the problem why I
cannot flash a new firmware?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/betaflight/betaflight-configurator/issues/200#issuecomment-250976001,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAYZms1w36u6n48DcmUDacSFrNKCA-T1ks5qv8kOgaJpZM4JgPh_
.

[kaefert]

Hey there Nathan, thanks for the reply!
Sorry to say but I already tried around a dozen times. It does not seem to change. I also shutdown and rebooted my laptop, did not help neither..

[kaefert]

when I press the "Flash Firmware" button again, it simply prints the same 3 lines with the current timestamp again and counts up the USB device ID (2 instead of 1):

2016-10-02 @ 17:18:43 -- USB device successfully opened with ID: 2
2016-10-02 @ 17:18:43 -- Detected device with total flash size 256 kiB
2016-10-02 @ 17:18:44 -- USB device successfully closed

[AndersHoglund]

Just to confirm. Do you have "Full Chip Erase" enabled or not?

Also, the SPRF3EVO binary is about 146kByte. When this is encoded into a human readable .hex text file it becomes about 3 to 4 times larger. Still exactly the same binary content and size, only in another file format.

[kaefert]

I tried both with and without "Full Chip Erase", the result does not change.
Thanks for the explanation about the hex file size.

[mikeller]

@kaefert: Boards that are using VCP often run into problems with the drivers used on the host PC side, since they change their USB device type between ACM and DFU mode. What host OS are you using?

[kaefert]

when I wrote about my problem here I was using Linux Mint 18 (=Ubuntu 16.04). Since then I also contacted the seller of the flight-controller who sent me a PDF with instructions for flashing on Windows. I tried to follow these using a borrowed Windows 10 laptop, but the result was exactly the same as with my Linux machine (those 3 lines from 4 comments above appear instantly and nothing happens afterwards)

What's interesting is, that I learned from this PDF that I did not need to short the BOOT pads to get into DFU-mode, but instead just pressing the "Flash Firmware" button while in the default (I guess that's what you just called ACM) once makes the flight-controller switch into DFU mode.

[mikeller]

I can't help you much for Windows, since I am not using it (at least as much as I can avoid). In linux, problems with VCP devices seem to often come from modemmanager running in the background, and claiming the device as soon as it becomes available. You could try disabling modemmanager systemctl disable modemmanager, and then try again under linux.

[fgrano]

I'm having this exact same problem. Feels like I've tried everything...
All the zadig stuff, different usb ports, different computers, windows 10, linux (debian).
Nothing helps, still stuck at "Erasing ..."
This is all I get in log:

2016-10-12 @ 00:54:14 -- Loaded release information from GitHub.
2016-10-12 @ 00:54:23 -- USB device successfully opened with ID: 33
2016-10-12 @ 00:54:23 -- Detected device with total flash size 1024 kiB
2016-10-12 @ 00:54:24 -- USB device successfully closed

Really hope someone finds a solution to this! I have no more ideas..

[skaman82]

Having exact the same problem with a SPF3racingEVO brushed board on OSX. Tried everything but still can't flash the board. It connects without problem to CF configurator (CF 1.13 installed). When I try to flash betaflight the status bar hangs on Erasing… (erase is not not selected btw). The log says:

Tried multiple baud rates, shorten boot pads, tested some different USB cables. No luck :( Never ever had difficulties with flashing all my various boards, never even had to bridge boot pins to do it).

[mikeller]

@skaman82 When bridging the boot pins, did you enabling 'No reboot sequence'? (That's how it is intended to work.)

Also, I've had success in the past with difficult cases by enabling 'No reboot sequence' and 'Flash on connect'. (The process will start immediately after the boot pins are released, so do a couple of tries of connect boot pins - plug in - release boot pins - watch progress bar...

[skaman82]

@mikeller yes also tried that without success and got the same hanging behavior

[kaefert]

@mikeller I disabled and stopped the ModemManager like this:

$ sudo systemctl disable ModemManager
Removed symlink /etc/systemd/system/multi-user.target.wants/ModemManager.service.
Removed symlink /etc/systemd/system/dbus-org.freedesktop.ModemManager1.service.
$ sudo systemctl stop ModemManager

But the result does not change

2016-10-12 @ 18:29:44 -- USB device successfully opened with ID: 3
2016-10-12 @ 18:29:45 -- Detected device with total flash size 256 kiB
2016-10-12 @ 18:29:45 -- USB device successfully closed

The Cleanflight Configurator has the same problem when trying to flash a new firmware. It can connect and configure the flightcontroller in it's current state though, but I have the additional problem that the brushed motors slowly loose power after a few seconds, therefore the flightcontroller is completly useless and I made the seller on aliexpress refund my money. (The motors and the battery are not at fault, both work fine together with a proprietary Hubsan flightcontroller)

@skaman82 Since you seem to struggle with the same flightcontroller as me here: Did you try to configure the firmware it came with and try to fly it? Does it fly?

[mikeller]

Hmm, sounds like something is seriously wrong with this board. (Wouldn't be the first thing I've seen on aliexpress that is broken by design.) I assume there will be a way to flash the MCU via ICSP, but that would probably require soldering onto the chip's pins...

[AndersHoglund]

Have you checked what Windows device manager has to say about the STM32 DFU device and the drivers? Probably no issues there as it shows up as "DFU" in BFC, so it seems to be detected and enumerated OK. But just to check in any case....
Do we have some other F3 VCP targets to compare? LUX for example. Are all F3 VCPs broken or just some? I only have two Revo (F4) clones, and those are only "semi broken". Works fine when "Full chip Erased" is disabled.

[skaman82]

@kaefert yes it flies quite good on CF 1.13. Config is also working fine.
@AndersHoglund I am using OSX

The strange thing is: I tried to flash this board (from aliexpress) with all three configurators without success so I don't think we have a bug in the configurator. I also got the same board from banggood before and had no difficulties to flash it with betaflight - to sad that I gave the working one away, so I can not compare the two boards directly.

[ghost]

I also have this problem on Flip32 F4 Flightcontrol
Connect with boot short, and BF config show DFU mode correctly.
I try to select full chip erase and not select it, the problem exist both.
Just stop at the erase, and log show USB device successfully closed.
Using Zadig and select WinUSB(7600.16385).

[jaisor]

Same issue with a Readytosky (?!) F4 board that recognizes as REVO. It came flashed with BF3.0. Tried to reflash and it hangs in Erasing with DFU selected. I'm running OSX.

[marcroe]

It appears that write and/or read protection is active for the memory of these boards. Checking the console output of BF configurator, the DFU command for erasing the memory returns an error code. Chip erase should normally not result in an error, even if write protection is active (bootloader just doesn't execute the erase operation). This would mean read protection is enabled, which is also congruent with what dfu-util and dfu-tool on Linux report when I tried to read/download the contents of the flash from one of those F4 clones.

[blckmn]

Good find. We should add this to Configurator to advise the user. We should probably fix the full chip erase for F4 so as to ensure flashing can occur.

[marcroe]

I agree. If it's only level 1 read protect, we can disable it by setting the right option bytes in memory. I'll have to delve more into ST's docs on the F4...
I have two Revo clones lying around and I want to upgrade them to BF3.0.1 or RF to make the buzzer work. Without flashing they are stuck at BF3.0.

[danielolsman]

I had the same problem, i think i found a solution:

http://www.rcgroups.com/forums/showpost.php?p=35965420&postcount=384

[marcroe]

Thanks a lot. I will try your method. Maybe we can add a 'read un-protect' routine to the configurator?

[nathantsoi]

Cool, this is the same thing I had to do for the kissfc. Like this:
https://nathan.vertile.com/blog/2016/07/29/betaflight-kiss-flight-controller/#flashing

On Mon, Oct 17, 2016, 6:16 AM mrroe [email protected] wrote:

Thanks a lot. I will try your method. Maybe we can add a 'read un-protect'
routine to the configurator?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/betaflight/betaflight-configurator/issues/200#issuecomment-254204003,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAYZmp4jUQaPnp-TiAl1SmCfL4XININVks5q03UdgaJpZM4JgPh_
.

[RadioC]

Confirmed Daniel's method works. Just to expand on what you have to do:

1. Connect the board to an FTDI adaptor using the UART pins on the board. Make sure tx and rx are reversed (so tx on the FCB connects to rx on the FTDI, etc)
2. Check you can connect to the board in betaflight via the FTDI ataptor to confirm you have it wired up correctly. If you cannot connect using the FTDI's comm port you've got the wiring wrong.
3. Download and install the flasher stm32 software from here: http://www.st.com/content/st_com/en/products/deve...
4. Power up the board IN BOOT MODE
5. Open the flash loader software, select the correct comm port. Click next.
6. Click REMOVE PROTECTION. Wait while it does it's thing.
7. Restart the board, you should now be able to connect in boot mode via the normal USB, and do the flash as normal (Will require the usual Zadig driver replacment, but make sure you're connecting via USB and not via the FTDI adaptor before you swap out any drivers with Zadig).

[marcroe]

Yes - it works.
I wrote a little script that 'unprotects' the chip via USB (no FTDI adaptor required). Planning to add this to the configurator.

[skaman82]

@marcroe great, really looking forward to that one! I leave my board as it is (for now) so I can test your script later.

[AndersHoglund]

Great. But just to clarify. Does this solve the original problem of flash hanging only when "Full chip erase" is enabled, and when disabled flashing works OK ? I.e. Chip is not totally locked.

Or do we have two different problems here? 1. Only erase locked as of above 2. Total locked chip.

[marcroe]

I added some support to remove the read protection here:
https://github.com/marcroe/betaflight-configurator
It's very rudimentary, but I tried to make sure it won't brick any boards (can't give any guarantees, of course). I believe removing read protection via DFU is slightly safer than over serial.
The way it works is by trying to read the option bytes sector of the memory. If it fails it assumes that read protection is active and tries to unlock the chip. This indicator seems to be reasonable, but maybe there are better ways to detect read protection.
Also, my code hasn't been tested very thoroughly. I did not feel comfortable locking and unlocking my boards repeatedly :)

if anyone wants to give it a try:
Connect board in DFU mode. Try flashing. Protection will be removed if present. Board reboots. Re-connect board in DFU mode. Try flashing again.

@AndersHoglund It could be two problems although I think it is unlikely, at least for F4 boards. I have a genuine Revo and a cheaper Revo clone. Both of them have no issues erasing the memory, local and mass erase. Mass erase takes slightly longer and it sometimes appears as if there's no progress. However, it has always worked. Btw, I am using Linux only. could be a different story on another OS.

[AndersHoglund]

@marcroe ,Finally tested your variant of BFC on Win10. Still disconnects within 5sec and hangs in "Erasing" with my RTFQ Revo Acro . I will leave it "Hanging", if it is a sloow erase.... Tried that before though, no luck then.

2016-10-18 @ 12:06:20 -- USB device successfully opened with ID: 3
2016-10-18 @ 12:06:20 -- Detected device with total flash size 1024 kiB
2016-10-18 @ 12:06:20 -- Read protection not active
2016-10-18 @ 12:06:25 -- USB device successfully closed 

Tried it both ways, hard DFU with bootpads shorted and soft DFU with betaflight 3.0.1 running.

[skaman82]

@marcroe tested your branch today. After I clicked the flash button the status bar said to reconnect the board but the board does not connect anymore to the configurator and seems to bee in DFU mode. So it is bricked for now.

[marcroe]

@skaman82 When read protection is removed, everything on the board except for the bootloader is erased, it automatically performs a reboot and remains in an "unknown" state (http://www.st.com/content/ccc/resource/technical/document/application_note/6a/17/92/02/58/98/45/0c/CD00264379.pdf/files/CD00264379.pdf/jcr:content/translations/en.CD00264379.pdf).
Have you put the board manually in DFU mode again when connecting the second time (after removing read protection)? Does it show "DFU" in the drop-down list in the top right corner of the configurator? If so, try flashing again. The second time it should run through all the way and flash the hex. Do you remember what the log in the GUI said? Also, do you know what type of F4 chip it is?
@others: please use my modification with extreme caution. Though, all it does is trying to read the option bytes and then execute the read unprotect command on page 20 of the above PDF. No other write operations.
@AndersHoglund yeah. you were right. seems to be two independent problems. Can you maybe let me know what the log says? The actual log, not the one shown in the GUI. You have to open chrome and enable "developer mode". After that navigate to chrome://inspect while you are running the configurator. Then go to "apps" and click "inspect" for the instance of the configurator that is currently running. This will open a developer mode window which has a "Console" tab. This is the actual log where the output of "console.log(...)" goes to.

[skaman82]

@marcroe It is a F3 EVO bushed board btw. I assumed it was already in DFU mode after I clicked the flash button first time. Now the configurator can not find the device if I connect via USB. I will try to short the boot pads later when I am back at home.

[AndersHoglund]

OK, here are the console log:

Loading file from: E:\Users\andho\Documents\Modellflyg\cleanflight\FirmWare\borisb\betaflight_3.0.1-30-e630de9_BUZZERM6 Release\betaflight_3.0.1_REVO.hex
firmware_flasher.js:234 File loaded
hex_parser.js:106 HEX_PARSER - File parsed in: 0.0560 seconds
stm32usbdfu.js:93 USB DFU detected with ID: 7
stm32usbdfu.js:132 Device opened with Handle ID: 6
stm32usbdfu.js:162 Claimed interface: 0
stm32usbdfu.js:630 Address load for option bytes sector succeeded.
stm32usbdfu.js:577 Option bytes read successfully
stm32usbdfu.js:578 Chip does not appear read protected
stm32usbdfu.js:647 Executing global chip erase
stm32usbdfu.js:106 reporting chrome error: Transfer timed out.
stm32usbdfu.js:383 USB transfer failed!
stm32usbdfu.js:385 USB transfer result code: 2
stm32usbdfu.js:660 Failed to execute global chip erase
stm32usbdfu.js:937 Script finished after: 5.283 seconds
stm32usbdfu.js:172 Released interface: 0
stm32usbdfu.js:147 Device closed with Handle ID: 6

[AndersHoglund]

Found an interesting statement in ch 3.4 : www.st.com/resource/en/application_note/CD00167594.pdf

Some products don’t support Mass erase operation. To perform a mass erase
operation using bootloader, two options are available:
 – Erase all sectors one by one using the Erase command
 – Set protection level to Level 1. Then, set it to Level 0 (using the Read protect
 command and then the Read Unprotect command). This operation results in a  
 mass erase of the internal Flash memory.

I have not been able to find out which ST products though.....

Simple "fix" would probably be to remove "Full Chip Erase" from the BFC GUI when a F4 is connected. Same Q&D fix as RFC uses, no "Full ChipErase" there.

[marcroe]

I didn't know that some chips don't support mass erase. Thanks! According to your logs it could also be the USB connection timing out. I added a timeout of 60 seconds when waiting for the reply of the mass erase operation (only works in Chrome v43 or higher). It takes between 10 to 18 seconds for my boards (Revo and Revo clone) to erase the entire memory. The measured time is displayed in the GUI log.
However, I'd also suggest moving away from mass erase.

@skaman82 Great! Let me know what the outcome of flashing a second time is and if it unbricks your board.

[skaman82]

@marcroe flashing again in configurator with boot pins shortened was a success for me! Finally I can flash the board with firmware of my choice! Thanks

[marcroe]

Awesome. Glad to hear that :)

[kaefert]

@marcroe your mod worked for my SP RACING F3 EVO Brush too!

first step:

2016-10-19 @ 12:26:49 -- USB device successfully opened with ID: 1
2016-10-19 @ 12:26:49 -- Detected device with total flash size 256 kiB
2016-10-19 @ 12:26:49 -- Chip seems read protected. Initiating read unprotect
2016-10-19 @ 12:26:49 -- Unprotect memory successful. Unplug and re-plug flight controller please!
2016-10-19 @ 12:26:49 -- USB device successfully closed

and afterwards with bridged boot pins the real flashing:

2016-10-19 @ 12:39:19 -- USB device successfully opened with ID: 3
2016-10-19 @ 12:39:19 -- Detected device with total flash size 256 kiB
2016-10-19 @ 12:39:19 -- Read protection not active
2016-10-19 @ 12:39:23 -- Erased 148 kB of flash successfully
2016-10-19 @ 12:39:31 -- USB device successfully closed

Thank you marcroe!!

[marcroe]

Rethinking this, I figure that my unprotect routine seems to be quite safe. The only exception could be a user disconnecting the board while it is still erasing the memory. The bootloader actually performs a mass erase after read protection is removed and then reboots into some "unknown" state. Therefore, I now introduced a pseudo-delay of 20 seconds to make the user waits after initiating the unprotect command (my boards take up to 18 seconds when performing mass erase). Unfortunately, we don't really have an idea how long erasure takes. We can only guess by manually triggering a mass erase and timing it.
So, when using my branch/modification, either use the newest version of my branch or make sure to wait for a bit after it instructs to unplug and re-connect, say, 10 seconds or so.

[domi1988]

I tried to remove the protection with ftdi adapter, but the stm32 flash loader allways says: "no response from the target, the boot loader can not be started..."
my F3 evo brushed is in boot mode, and betaflight configurator detects it as com4.
what did i do wrong?
how does the second method with the usb port work exactly???
PLZ HELP!

[marcroe]

@domi1988 Git clone the branch from here: https://github.com/marcroe/betaflight-configurator
and install it following the instructions found here: https://github.com/betaflight/betaflight-configurator/blob/master/README.md
using the "alternative way".
Let me know if it "unprotects" your board successfully :)
@AndersHoglund It would be awesome if you could try reproducing the USB timeout with my newest version.

[domi1988]

@marcroe thank you sooo much! it finaly flashed the f3 evo brushed and i dont have to buy a new one!

[AndersHoglund]

Can't see much change in behaviour. Here are the inspect log:

Loading file from: betaflight_3.0.1-30-e630de9_BUZZERM6 Release\betaflight_3.0.1_REVO.hex
firmware_flasher.js:234 File loaded
js/workers/hex_parser.js:106 HEX_PARSER - File parsed in: 0.0570 seconds
stm32usbdfu.js:93 USB DFU detected with ID: 8
stm32usbdfu.js:132 Device opened with Handle ID: 10
stm32usbdfu.js:162 Claimed interface: 0
stm32usbdfu.js:654 Address load for option bytes sector succeeded.
stm32usbdfu.js:599 Option bytes read successfully
stm32usbdfu.js:600 Chip does not appear read protected
stm32usbdfu.js:671 Executing global chip erase
stm32usbdfu.js:106 reporting chrome error: Transfer timed out.
stm32usbdfu.js:392 USB transfer failed!
stm32usbdfu.js:394 USB transfer result code: 2
stm32usbdfu.js:688 Failed to execute global chip erase
stm32usbdfu.js:965 Script finished after: 5.275 seconds
stm32usbdfu.js:172 Released interface: 0
stm32usbdfu.js:147 Device closed with Handle ID: 10

[mascaras35]

@marcroe im waiting for a Raceflight F4 CC3D revo so if i undertsand and my FC its read protected and i dont have a FTDI i should use this steps :

Connect board in DFU mode. Try flashing. Protection will be removed if present. Board reboots. Re-connect board in DFU mode. Try flashing again.

???

Did i understand well?

thanks for your help

[marcroe]

@mascaras35 Hi ! Yes this is pretty much it. Actually, if your board is a "genuine" one, there shouldn't be any read protection. At least mine wasn't protected. Some of the clones apparently are protected though.

Thanks @AndersHoglund . Somehow the timeout parameter is not implemented correctly in the chrome.usb API. I did set the timeout to 60 seconds, but yet flashing terminates just after 5 seconds in your case (Script finished after: 5.275 seconds).

[AndersHoglund]

OK, re-test with PR #344. Ref issue #341 also.

Now I see erase progress bar updates 3 times. Then it goes "Flashing" with progress bar fully right. No restart of progress bar. USB is however closed, and it seems to hang in this state. Disconnect and re-connect USB, nothing is actually flashed. App log:

2016-11-19 @ 12:53:49 -- USB device successfully opened with ID: 21
2016-11-19 @ 12:53:49 -- Detected device with total flash size 1024 kiB
2016-11-19 @ 12:54:05 -- USB device successfully closed

Then I opened Chrome inspect to get a full console log. And behold, now everything works! Tried both with forced DFU mode "No reboot" and normal soft DFU mode. Both worked. The progress bar even restarts properly, going from left to right when flashing. The Console log for both tests:

SB DFU detected with ID: 21
stm32usbdfu.js:131 Device opened with Handle ID: 22
stm32usbdfu.js:156 Claimed interface: 0 
stm32usbdfu.js:472 Executing global chip erase
stm32usbdfu.js:105 Transfer timed out.
stm32usbdfu.js:339 USB transfer failed!
stm32usbdfu.js:341 2
stm32usbdfu.js:105 Transfer timed out.
stm32usbdfu.js:339 USB transfer failed!
stm32usbdfu.js:341 2
stm32usbdfu.js:105 Transfer timed out.
stm32usbdfu.js:339 USB transfer failed!
stm32usbdfu.js:341 2
stm32usbdfu.js:584 Writing data ...
stm32usbdfu.js:642 Writing: done
stm32usbdfu.js:656 Verifying data ...
2stm32usbdfu.js:435 Verification successful, matching: 65536 bytes
stm32usbdfu.js:435 Verification successful, matching: 36180 bytes
stm32usbdfu.js:723 Programming: SUCCESSFUL
stm32usbdfu.js:770 Script finished after: 26.081 seconds
stm32usbdfu.js:166 Released interface: 0
stm32usbdfu.js:146 Device closed with Handle ID: 22
port_handler.js:99 PortHandler - Found: COM6
port_handler.js:31 PortHandler - Removed: COM6
port_handler.js:99 PortHandler - Found: COM6
serial.js:116 SERIAL: Connection opened with ID: 112, Baud: 115200
stm32.js:90 Sending ascii "R" to reboot
serial.js:167 SERIAL: Connection with ID: 112 closed, Sent: 1 bytes, Received: 0 bytes
port_handler.js:31 PortHandler - Removed: COM6
stm32usbdfu.js:92 USB DFU detected with ID: 22
stm32usbdfu.js:131 Device opened with Handle ID: 23
stm32usbdfu.js:156 Claimed interface: 0
stm32usbdfu.js:472 Executing global chip erase
stm32usbdfu.js:105 Transfer timed out.
stm32usbdfu.js:339 USB transfer failed!
stm32usbdfu.js:341 2
stm32usbdfu.js:105 Transfer timed out.
stm32usbdfu.js:339 USB transfer failed!
stm32usbdfu.js:341 2
stm32usbdfu.js:105 Transfer timed out.
stm32usbdfu.js:339 USB transfer failed!
stm32usbdfu.js:341 2
stm32usbdfu.js:584 Writing data ...
stm32usbdfu.js:642 Writing: done
stm32usbdfu.js:656 Verifying data ...
2stm32usbdfu.js:435 Verification successful, matching: 65536 bytes
stm32usbdfu.js:435 Verification successful, matching: 36180 bytes
stm32usbdfu.js:723 Programming: SUCCESSFUL
stm32usbdfu.js:770 Script finished after: 26.138 seconds
stm32usbdfu.js:166 Released interface: 0
stm32usbdfu.js:146 Device closed with Handle ID: 23
port_handler.js:99 PortHandler - Found: COM6

[mikeller]

@AndersHoglund did you try again without the full console log? Did it still work?

[ridgeracer]

I had the same issue with my F4 Revo. To get the flash to work I only selected manual baud rate of 256000 in DFU connection. All other options I left off. Worked fine afterwards however every time I save a change in the GUI it disconnects the serial port.

2016-11-20 @ 02:39:40 -- Running - OS: Windows, Chrome: 54.0.2840.99, Configurator: 1.8.4
2016-11-20 @ 02:39:48 -- Please use the Firmware Flasher to access DFU devices
2016-11-20 @ 02:39:58 -- Failed to open serial port
2016-11-20 @ 02:40:10 -- Using cached release information.
2016-11-20 @ 02:40:48 -- USB device successfully opened with ID: 1
2016-11-20 @ 02:40:48 -- Detected device with total flash size 1024 kiB
2016-11-20 @ 02:40:53 -- Erased 256 kB of flash successfully
2016-11-20 @ 02:41:08 -- USB device successfully closed
2016-11-20 @ 02:41:35 -- Serial port successfully opened with ID: 1
2016-11-20 @ 02:41:35 -- MultiWii API version received - 1.21.0
2016-11-20 @ 02:41:35 -- Flight controller info, identifier: BTFL, version: 3.0.1
2016-11-20 @ 02:41:35 -- Running firmware released on: Oct 18 2016 10:26:33
2016-11-20 @ 02:41:35 -- Board: REVO, version: 0
2016-11-20 @ 02:41:35 -- Unique device ID received - 0x43001c3535511937393930
2016-11-20 @ 02:42:03 -- EEPROM saved
2016-11-20 @ 02:42:04 -- Unrecoverable failure of serial connection, disconnecting...
2016-11-20 @ 02:42:05 -- Serial port successfully closed
2016-11-20 @ 02:42:13 -- Serial port successfully opened with ID: 2
2016-11-20 @ 02:42:13 -- MultiWii API version received - 1.21.0
2016-11-20 @ 02:42:13 -- Flight controller info, identifier: BTFL, version: 3.0.1
2016-11-20 @ 02:42:13 -- Running firmware released on: Oct 18 2016 10:26:33
2016-11-20 @ 02:42:13 -- Board: REVO, version: 0
2016-11-20 @ 02:42:13 -- Unique device ID received - 0x43001c3535511937393930
2016-11-20 @ 02:42:17 -- CLI mode detected
2016-11-20 @ 02:51:16 -- CLI reboot detected
2016-11-20 @ 02:51:16 -- Device - Rebooting
2016-11-20 @ 02:51:16 -- Serial port successfully closed
2016-11-20 @ 02:51:18 -- Serial port successfully opened with ID: 3
2016-11-20 @ 02:51:19 -- MultiWii API version received - 1.21.0
2016-11-20 @ 02:51:19 -- Flight controller info, identifier: BTFL, version: 3.0.1
2016-11-20 @ 02:51:19 -- Running firmware released on: Oct 18 2016 10:26:33
2016-11-20 @ 02:51:19 -- Board: REVO, version: 0
2016-11-20 @ 02:51:19 -- Unique device ID received - 0x43001c3535511937393930
2016-11-20 @ 02:51:31 -- Serial port successfully closed
2016-11-20 @ 02:51:33 -- Using cached release information.

[AndersHoglund]

@mikeller When running without logging it still hangs. Sorry. I should have mentioned that of course. Will test some more, as it might be marginal timing. But still, failure seen when running without logging.

@ridgeracer , There is no baudrate on DFU or other USB generic devices, only on USB-serial (RS232 emulation) stuff. This case is all about the "Full Chip Erase" setting. And now logging.

Disconnects after saving seems to be a normal behaviour, annoying yes. Start a new issue on that.

[estauss]

@marcroe, fantastic work. I have been struggling to find a solution for the last few hours to flash BF/RF. Unpacked and loaded your branch and it removed the read protection and then flashed; FINALLY.
Libre pilot was working fine with the read protection enabled.

Aliexpress Revo clone,
Windows 10

FIX: Git clone the branch from here: https://github.com/marcroe/betaflight-configurator
and install it following the instructions found here: https://github.com/betaflight/betaflight-configurator/blob/master/README.md
using the "alternative way".

[AndersHoglund]

Re-tested marcroes fork of BFC. Still hangs when trying to flash with "Full Chip Erase" enabled, same as the ordinary BFC.

[mikeller]

@AndersHoglund Have you tested recently with stock Betaflight configurator? #344 might have fixed it.

[AndersHoglund]

Oh yes, that is old. Tested that 5days ago. Scroll up a bit and you see it. Last tests was done with 347 merged, the current HEAD.

[marcroe]

@estauss Thanks. Glad to hear it worked!
I rebased my branch to include #344, i.e. the manual timeout when erasing.
@AndersHoglund If I understand correctly, the manual timeout works for you when your console is open (chrome inspect)? Very strange indeed.

[mikeller]

@marcroe Would you be interested in submitting a pull request for your changes?

[marcroe]

Sure, just made a request. See #350

[Chadster]

I confirmed the DFU flashing protection solution worked on a LHI branded F3 EVO brushed board. Thank you so much for this fix! I was going crazy trying to get my board to flash.

[mikeller]

@Chadster Can you please test with #350, to confirm that nothing went wrong in the PR itself?

[JaYp247]

I have a CC3D Revo F4 Acro board and I used the method below to Flash Betaflight 3.0.1. I need others to confirm.

1. Solder/Jumper boot pads
2. Plug in USB, run Zadig as administrator, Go to Options list all Devices.
3. Select STM 32 Bootloader from the drop down, click Install
4. Open Betaflight, where the com ports are listed, mine read DFU
5. Click Firmware Flasher
6. Set your options to those I have in the picture
   
7. Click Load Firmware Online
8. Click Flash Firmware
9. De-solder/remove jumper boot pads
10. Test with Betaflight Configurator

[AndersHoglund]

Almost complete, just a few extra steps.

1. Select the STM32 BOOTLOADER device.
   3.1 Select the "WinUSB (v6.1.7600.16385)" as a replacement for the default STM DFU Driver.
   3.2 Click "Re-install Drivers".

9.1 Download and install the "STM32 VCP driver", http://www.st.com/en/development-tools/stsw-stm32102.html

1. Optional. Do a "Reset Settings" in the the BFC GUI. Or the "defaults" command in CLI.

With BF up and running you do not need to do all this to update firmware. Just un-tick "No Re-boot Seq.." and run steps 5 to 8. You only need to do all this on a FC not responding when using BFC, "un-bricking".

Oh, no need to set any baud-rate. Does not apply for USB-DFU devices. But it does no harm either, as it does not matter. Could/should really be greyed out.

The important part, which this issue is all about, do NOT enable "Full Chip Erase". Do step 11 instead.

[JaYp247]

Ahh. Thanks for the help.

[JohannesKn]

Hi, with my F3 evo I can`t do anything.
Tried the solution of marcroe butr does not work.

2016-12-25 @ 12:08:24 -- Please use the Firmware Flasher to access DFU devices
2016-12-25 @ 12:08:25 -- Using cached release information.
2016-12-25 @ 12:08:35 -- USB device successfully opened with ID: 15
2016-12-25 @ 12:08:35 -- USB device successfully closed

Get nothing more than this.
Sometimes it shows me this. After that I have to reconnect the FC.

2016-12-25 @ 12:03:01 -- Using cached release information.
2016-12-25 @ 12:03:35 -- Please use the Firmware Flasher to access DFU devices
2016-12-25 @ 12:03:37 -- USB device successfully opened with ID: 12
2016-12-25 @ 12:03:37 -- Detected device with total flash size 256 kiB
2016-12-25 @ 12:03:47 -- Failed to open USB device!

Any idea what else can help?
Getting crazy over this sh**ty FC, never had problems like this.

Many thanks for any help!!

[RipperDrone]

I tried @marcroe 's version of BFC, it didn't change the issue. In my log, there was a status "not read protected" anyway, so I don't think this is the problem in my particular case. The USB connection seems to be closed just after mass erasing the flash memory. And then there is no way to USB connect. Must be hardware / port failure...

[AndersHoglund]

STM32 F4 chips has asymmetric flash sector/page sizes, 16k, 64k and 128k while BFC assumes all pages equal. Could be the reason for problems.
F1 flash pages are all equal in size, also F3. F7 flash is asymmetric too.

[mikeller]

Good finding, @AndersHoglund!

[AndersHoglund]

Asymmetric flash sectors is not a problem when using USB DFU. Only a major problem when connecting to bootloader via a UART. An F3 with a dead USB port can still be flashed over a serial port, but not any F4 or F7. But that is not the topic of this case, different issue #477.