I have seen at least half a dozen reports of issues updating firmware to/from 4.0+, had to reflash bootloader prior to 3 of my own ESCs taking the flash. This behavior was only present with this latest release, previous versions had updated on the same hardware without issue.
Probably worth noting, might be correlation.
Can you send me the CSV you posted via mail? Or better directly to Benjamin Vedder.
Wil send you a PM with email.
Newer versions have compression to speed up wireless FW updates. VESC-Tool is clever enough to figure out which FW is which. The only issue might be Ack FW, since VESC thinks its newer, due to versioning.
I tried to downgrade and update in between all sorts of FW versions and it all went smooth all the time. Tried it on a HW 4 and HW 6.
Hi there @Trampa 
one of these is me. Going from 3.65 to 4.0 on two brand new VESC 6 MK3 and I get this error on one of them:
To my knowledge, neither did I. I will be doing more investigation when I get home today.
Let me find the screenshot from Frank a while back.
And don’t forget to click disconnect after.
It’s pretty straight forward.
Ah thanks! Just need to find out if the second V6 can upload FW.
Noob question, is the swd prog for flashing the bootloader or the FW itself?
Firmware itself and bootloader should be come with it if I remember right.
I think I just did a normal FW update after I flashed via swd just to be sure.
For the cable you can use your wand swd cable. Should work.
You can do both technically, it’s a ‘bare-metal’ interface that allows you to write the entire flash of the MCU without using USB (which is a device that the MCU has to host). Generally you flash the bootloader with SWD, which then allows you to load a program on it over USB, but I believe the vesc-tool scripts these together.
And to expand: The bootloader is a little program that executes at startup and allows the USB programming function to work + starts the program running on the MCU.
Great explanation, thanks! 
is there a version history or changelogs for the bootloader? can an esc running a bootloader that was applied by a 2.x or ack bldc/vesc-tool app be programmed with firmware 4.x?
Based on the reports I’ve seen with this 4.0+ release, it looks like there are varying degrees of success on this.
5 mentions of bootloader in the ChangeLog but not a ton of specifics:
Fingers crossed for OpenRoad…
You can upload the FW, using the old bootloader. If the FW changes, the bootloader worked just fine, if the FW does not upload there is no bootloader on the ESC and you can load the missing bootloader.
That is correct.
hi frank, thank you so much for your reply
is compressed firmware transfer a feature that is built into the bootloader? that is to say, is it possible that i could use the latest vesc-tool with the intention of applying the latest 4.x firmware, but if the bootloader on my ESC is too old i would have to patiently wait for the firmware to be transferred uncompressed?
i’m glad that esc’s running old bootloaders can accept the latest firmware. is the reverse also true? once i apply the latest bootloader to an ESC, should i anticipate any issues trying to apply an old firmware?
I just had a longer conversation about the wobble that can happen due to the Time Constant.
Benjamin is fixing the issue right now.
The good news: We will probably use this matter to find a way to detect wobbles in future, so that the VESC can work against speed wobbles and stabilize the rear truck, using both motors to create a counter oscillation.
The other thing that will become available in one of the next updates is button to go back to the old setup.
Basically the entire device software and config will be saved prior to the FW update, so that a single click will bring you back to your old setup and config. Like in any software, you can press that BACK button and you are back to what you had before.
We will advise users to keep an existing setup and config if it worked good for you in the past.
You can then try out the latest FW and see if that works even better for you, or enjoy/try new features, but you can also just go back and use your stable setup again.
Why hasn’t anyone thought of this before? That’s a great idea.
At least we want to get something positive from this and since motors can react very fast to an occurrence, it is possible. Benjamin Vedder likes to nail problems that pop up and can be solved. We will try to solve speed whobble.
Any discussion with him on using a dev/stable release model?
