Must be in DFU mode to upload firmware, unless dataflash is erased first

[joshuabardwell]

I cannot upload new firmware to my boards unless I am in DFU mode. This has always confused me because other people seem to be able to flash without going into DFU mode, and I was always able to do it on my Naze32, unless I messed something up. A viewer of mine pointed out that it seems that the configurator tries to erase the dataflash chip before upgrading the firmware, and this causes a timeout. This can be fixed by manually erasing the dataflash just before uploading the firmware. To my amazement, this seems to be correct, although I have a limited number of boards to test on.

Can this be fixed? Forcing DFU mode to flash firmware is a real pain on many copters with enclosed FC such as some ARF and RTF models, but also more enclosed frames like Armattan Armadillo for example.

[borisbstyle]

VCP targets really need to go into DFU mode. On non-VCP targets like naze32 there is a separate chip on the board what handles the serial connection to UART (acts as FTDI) If you would want to flash going in DFU mode you would have to use UART with ftdi. But why do you have problems going into DFU? With zadig drivers setup correctly it should all be easy. You have to separately setup zadig for DFU and for normal configuring in case you didnt know.

[borisbstyle]

If its set correctly it goes into DFU automatically on flash button.

[Rossbow]

@joshuabardwell You can try the method I use

When you try to flash the FW and it fails, do not unplug the board from usb, now just go to the zadig program and replace or update the win driver, when its complete unplug the usb and reconnect it, now when you go into BF and try to flash the fw it will automatically change to dfu mode and install the fw.
When you are flashing different boards or change to a different computer you could have it happen again and just do the same again, works with all boards I have tried so far

[joshuabardwell]

To address these questions:

I am using a board with CP210. This board should be able to flash without manually entering DFU mode. It only works when dataflash is manually erased before uploading new firmware.

Entering DFU mode is inconvenient if the FC has bootloader pads instead of button; if the FC is installed in a frame and is not accessible, such as with Holybro Shuriken; etc... There are lots of cases where it is inconvenient to manually enter DFU mode.

For VCP targets, if manual DFU mode is required, so be it. There are lots of CP210 targets that don't need it. I request that a change be made to the flashing procedure to avoid the need to manually erase flash to avoid the timeout.

@Rossbow my drivers are correct r.e. Zadig. Everything works 100% if I manually press the bootloader button.

[borisbstyle]

You never have to go into DFU mode on cp210 boards. You also dont need zadig drivers for those.

[joshuabardwell]

You never have to go into DFU mode on cp210 boards.

I respectfully disagree. I am basically never able to flash new firmware without going into DFU mode on the Xracer F303, for example. Clearing the dataflash chip before uploading is the only thing that has fixed it.

[borisbstyle]

You for sure dont have to. I have quite a few boards where it always works. But....there is a known windows driver bug on some cp210 versions and maybe thats what you mean. I forgot the exact cp210 part names as there are few different ones. But basically some versions of cp210 are buggy only on windows where flashing goes wrong in certain scenarios. I found a workaround. When flashing always connect. Than disconnect....disconnect cable / power and than connect cable and go to flash. So basically only go straight to flash and dont connect and read/write other things to the board prior flashing and dont flash on the first connect to this board. That might be the only explaination for your case that I know.

[blckmn]

There is a CLI command called dfu :)

it will put the board into DFU mode. It works for F4 - just not F3 yet (though is easily added for those targets too)

[blckmn]

Naze works fine with no reboot sequence turned off ...

[blckmn]

@joshuabardwell perhaps skipping erasing / checking the onboard BB flash during firmware upgrade will fix it... I have one F303 based board (with a CP chip) that will only flash if manual baud rate is set at 57600 and no reboot sequence is off.

[etracer65]

I'm really thinking this is a windows driver bug as Boris suggested. I use OSX and have X-Racer F303's (v1 and v2.1) in all my quads and never have had to go into DFU mode to flash them - with or without full chip erase (doesn't matter). This is across 6 different quads and with all the BF testing I've probably flashed them 100's of times! :)

On my desk I have some old Naze32 rev5's I use for testing and never have to go into DFU mode either (they also have the CP2102).

[etracer65]

There is definitely something wrong with either the CP210x drivers or the configurator (or Chrome) on Windows. Just took a clean (fully updated) Windows 10 machine, installed the latest CP210x and I get unreliable firmware flashing with both a Naze32 rev5 and X-Racer F303 (v2). Sometimes I can flash with no problems, sometimes the verify phase will stall and timeout, and other times there'll be a bootloader timeout and I have to use DFU mode. The workaround that Boris suggested (connect/disconnect, unplug, plug, flash) seems to allow the flash to start reliably but I still get intermittent timeouts during the verify phase.

Never have any of these problems on OSX and apparently everything is fine on Linux as well.

[borisbstyle]

Latest 3.0.0 RC13 has working dfu cli command so you can force it into DFU

[Samus1rebooted]

please help. failed to open serial port

[Samus1rebooted]

only will connect in cli mode I've downloaded all the latest drivers and version of both betaflight as well as cleanflight not sure what to do at this point

[jflyper]

@Samus1rebooted
We are sorry, the Betaflight issues is not a place for user support, but it is for reporting software issues and discussion to make the Betaflight software better.

Please redirect your support request to appropriate places on the net, such as a thread in RCG. You can look for a thread by entering your FC brand/model in the search dialogue there.

https://www.rcgroups.com/forums/search.php

[prof7bit]

Please reopen!

I can confirm this bug with BF 4.0.2 and newest configurator on Ubuntu Linux 18.04.
Emax Hawk 5 (Emax Magnum Stack, OmnibusF4)

When I try to enter DFU mode either with the DFU button in the configurator or with the flash button and there is data in the data flash it will not properly enter DFU mode. It will instead crash after reboot and the beeper continuously beeps (one continuous tone).

dmesg shows this when it reboots into DFU (an USB device appears but it is dead):

[13530.485628] usb 5-3: new full-speed USB device number 3 using ohci-pci
[13546.042383] usb 5-3: device descriptor read/64, error -110
[13561.687215] usb 5-3: device descriptor read/64, error -110                                                                                 
[13561.951227] usb 5-3: new full-speed USB device number 4 using ohci-pci
[13577.560062] usb 5-3: device descriptor read/64, error -110
[13593.148800] usb 5-3: device descriptor read/64, error -110                                                                                 
[13593.256907] usb usb5-port3: attempt power cycle
[13593.728897] usb 5-3: new full-speed USB device number 5 using ohci-pci
[13604.465450] usb 5-3: device not accepting address 5, error -110
[13604.649456] usb 5-3: new full-speed USB device number 6 using ohci-pci
[13615.474016] usb 5-3: device not accepting address 6, error -110
[13615.474059] usb usb5-port3: unable to enumerate USB device             

When I press the boot button while powering up the FC I see this instead (which is how it should be):

[13719.327325] usb 5-3: new full-speed USB device number 8 using ohci-pci
[13719.524411] usb 5-3: New USB device found, idVendor=0483, idProduct=df11
[13719.524414] usb 5-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[13719.524415] usb 5-3: Product: STM32  BOOTLOADER
[13719.524416] usb 5-3: Manufacturer: STMicroelectronics
[13719.524417] usb 5-3: SerialNumber: 355D384B3536

No matter what I do it won't enter DFU through software reset without freezing and activating the beeper unless I erase data flash!

When the data flash is empty it will allow me to enter DFU from software without a problem and without need for boot button, I can just press the "flash" button in betaflight configurator and it will immediately work.

When there is data in the flash it will show the above symptoms.