#How to download firmware from FC
1 messages · Page 1 of 1 (latest)
you cannot download the firmware itself (binary), but you can make backups of the settings.
you can do it via the CLI tab or the presets tab.
via CLI tab, type diff all to see just the difference from defaults.
or type dump all to see the entire config.
i personally perform both.
You can save the output to a plain-text file.
On the preset tab, simply click the Save backup button to retrieve and save a diff all.
There's no rookie here. 🙂 I know how to backup BF settings, but I didn't ask about that.
So there is no way to download the firmware? Not even with development tools from STM?
okay, sorry did not know you expertise level.
it seems there would be a way but i do not personally know of any.
if i search DFU-UTIL (the legacy tool that falshes) i do see --download option, but never tried.
Cool, no problem ... I haven't tried the download option either, so I'm asking if anyone has.
I am concerned with the possibility of copying firmware between FCs that use firmware that does not have a hex file backup or that is no longer available from the server.
nope --download actually means write (flash) :(
--upload means read. i'm playing now
That's what I thought too, I wasn't too confused about the switch, I hope we understand each other.
OK, thanks, I am waiting ...
i'm not succeeding.
i have some download with this, but not a the 1.xMB filesize i would expect.
dfu-util -a 0 --dfuse-address 0x08000000 --upload-size 1048576 --device 0483:df11 --upload FOX_F405HEX.hex
however, to answer this specifically, you can compile hex locally as well. this how how we as devs typically do it.
what means athe 1.x ? Edit: Ok, I see now ...
Well, I would have to know all the parameters of the original build in order to make the same build, and I won't know them...
when you create a cloud build, it links a log.
open the log and see the exact build command.
i prefer the non-docker because my environment is setup.
or you can use the docker environment for guaranteed setup same as cloud-server
You can also retrieve the build parameters using the status command
Betaflight firmware? What versions?
I guess we don't understand each other, so I'll try to explain clearly. E.g. i get my hands on an FC with an older version of BF, so I have nothing but the firmware in the FC. If I flash the firmware to a different version, I will never get back to the original. It can be a firmware version for a specific FC that is no longer available, e.g. a development version, it is not possible to get it through the standard configurator interface. The only thing I can think of is getting the firmware from FC.
And a copy of the firmware is required to be sure that it is really a copy, with a new build it will always be about whether something has been forgotten ... a copy of the current state is definitely needed.
try stm32 cube programmer. but generaly you doesn't need to store a hex - diff will contain version that you can get at any time from github
what do you mean by development version? why did you ever need old dev version when there are stable release and newer dev versions?
Precisely because new versions are not always stable, sorry ...
use version command to get commit id
if you scared of unstable versions you should stick with release ones
OK thanks. I'll try, I don't have a specific FC here, when I have one, I'll try...
And report back ...
And back to the beginning, Is there any way to find out the firmware id from the hex file?
Are these FCs running Betaflight? If so, you just need a CLI dump.
What do you mean by development version?
in CLI type version, git the git commit SHA. this may help find the exact dev version and it is likely it can be re-compiled.
report the results of
version
manufacturer_id
board_name
i will attempt to checkout the SHA and compile. if it is 4.4 or later, i would need to know the cloud-option. if it is prior, likely to need unified-target file. if it is 3.x, likely do not need further info.
but yes, other guys in here are correct. newer "releases" are better in most cases.
and also "Stable" is a misnomer, it's all "beta"-ware. often some fixes do not get back-ported to older releases.
OK, I am back, I am going to find 4605309d8.
Betaflight / STM32F7X2 (S7X2) 4.4.0 Apr 19 2023 / 13:01:47 (4605309d8) MSP API: 1.45
HGLR, HGLRCF722E
AFAIK it is not standard release of 4.4.0.
4605309 is 4.4.0, the d8 is something like subversion?
complete 4.4.0 id is 4605309d8253db0113d4c54d31fe8bd998f46401 but once more time - you don't need to use it - just flash latest stable version
It is the release version of 4.4.0
This version was made directly by haslinghuis. And is different from version 4.4.0, that is available. So how do I know exactly what version it is when it normally only searches for the first few characters?
And that is related to ... And back to the beginning, Is there any way to find out the firmware id from the hex file?
Other than just uploading it to FC?
Why do you think it is different?
I am not thinking ... https://github.com/betaflight/betaflight/issues/12634
and all the time he calls it 4.4.2 ....
Post the output of status in the CLI
But I feel like we're drifting away from the original questions. So I understand that by default it is not possible to get the firmware from FC and no one here has tried either. And also it is not possible to get the id from the hex file.
This just seems to be 4.4.0 with some custom defines
If you post the output of status, you can see the defines and the build command used
What do you mean by "ID from the hex file"?
It's just that if I have a BF firmware hex file, and I don't know anything about it, then without uploading it to FC I have no chance to find out what ID, what version of BF it is... And all this is only on the assumption that I simply overwrite the previous firmware.
Drifting away ... Different BF versions have different setup parameters, diff is useless if I don't know the BF version.
The diff lists the Betaflight version
$ git checkout 4605309d8
Note: switching to '4605309d8'.
$ git log --date=short --pretty=format:"%h%x09%an%x09%ad%x09%s" | head -n 1
4605309d8 Hans Christian Olaussen 2023-01-29 Increment EEPROM version for 4.4 (#12242)
make STM32F7X2
[...]
Linking STM32F7X2
[...]
Building STM32F7X2 succeeded.
apply your unified-target (and your dump), profit.
But also trust the guys that newer=better.
that link shows a bunch of 4.4.2, so such is confusing. newer broken and older fixed? confused. but i digress.
it is possible to get firmware and i said you how
but as I and other guys explined - you don't need to do it, just flash release
# version
# Betaflight / STM32G47X (SG47) 4.5.0 Mar 12 2024 / 20:57:45 (ecef09fdd) MSP API: 1.46
# config rev: 917c3f5
# board: manufacturer_id: AIRB, board_name: AIRBOTG4AIO
git show ecef09fdd
Take note of the PR and type # in here
Thanks, so it's 4.4.0 with added PRs from 4.4.2.
Thanks, I'll try the STM32 cube programmer when I get around to it.
So I had a bit of trouble with the DFU mode driver, but I'm already inside with the STM32Cube Programmer. I'm going to do some research.
FYI - So it is not a problem to download (upload) and save the firmware from any FC using the STM cube programmer. Just select read all and save as bin or hex. And at the same time I came to my second answer. In any hex browser or editor, the downloaded firmware can be browsed and the build information is stored there in ASCII, so it is easy to find what kind of firmware it is.
I'm glad I helped you figure it out, but I still don't understand why it's necessary
Of course, it's useless for the average BF user. For anyone who wants to do non-standard things, this is quite essential. I'm thinking of copying debugged and tuned firmware between numbers of quads with the same hardware. It's much faster than using the standard configurator and fiddling with restoring backup settings. There are more possibilities of use.
Why can't you just flash the firmware and a diff?
the only reason I see it useful is for manufacturers or for flashing big batches of military drones