Skip to content

common: add firmware update page - #7981

Open
peterbarker wants to merge 1 commit into
ArduPilot:masterfrom
peterbarker:pr/add-firmware-update-page
Open

common: add firmware update page#7981
peterbarker wants to merge 1 commit into
ArduPilot:masterfrom
peterbarker:pr/add-firmware-update-page

Conversation

@peterbarker

Copy link
Copy Markdown
Contributor

really just here to hold the table at the end showing what versions we support moving to and from

@peterbarker

Copy link
Copy Markdown
Contributor Author

(the numbers were me throwing darts, please suggest alternatives + justifications :-) )

Comment on lines +30 to +35
| 4.8 | 4.2 |
+--------------+--------------------------+
| 4.7 | 4.2 |
+--------------+--------------------------+
| 4.6 | 4.1 |
+--------------+--------------------------+

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

4.8(latest)
have to reformat table, this is what a user sees in firmware server

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Baro Thrust Compensation <common_baro_thrust_compensation>
Boat mode <boat-mode>
Bootloader Update <common-bootloader-update>
Firmware Update <common-firmware-update>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not put it on this page..rather additional-information.rst...

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would not put it on this page..rather additional-information.rst...

Done

Comment on lines +30 to +34
| 4.8(latest) | 4.2 |
+--------------+--------------------------+
| 4.7 | 4.2 |
+--------------+--------------------------+
| 4.6 | 4.1 |

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sub skipped 4.2, 4.3, 4.4, and 4.6, so should probably have 4.1 -> 4.5 and 4.5 -> 4.7/4.8.
If that's not valid for the other firmware variants then we could differentiate with some site filtering.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know whether it makes sense for this to be vehicle-specific.

In the linked PR, for example, I'm trying to remove some old conversion code. The version that was introduced and the version it's leaving aren't changing there.

We should add a note about Sub's missing versions, somehow, I guess? So a Sub user wanting to go from 4.1 to 4.8 would go via 4.5 not 4.6. (the table above is specifies the maximum jumps, not the suggested or actual jumps)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, just to emphasise - I opened this PR with "I made these numbers up". If there's general agreement that we want this then I'll try to come up with some real numbers.

@rmackay9 has previous suggested that a strict 3-version rule is the way to go. So you could go 4.5->4.8 but not 4.4->4.8 - but you could go 4.5->4.7->4.8

@rmackay9

Copy link
Copy Markdown
Contributor

I'll leave it to @Hwurzburg re whether we need a new page but here are some other pages that users might think are related:

@rmackay9

Copy link
Copy Markdown
Contributor

I think we should move the "Parameter Migration" section to the, "Loading Firmware" page

really just here to hold the table at the end showing what versions we support moving to and from
@peterbarker
peterbarker force-pushed the pr/add-firmware-update-page branch from a722fdb to 2da3e3f Compare August 27, 2026 01:30
@peterbarker

Copy link
Copy Markdown
Contributor Author

I asked Claude to flesh out the table for me:

● Done. The numbers you threw darts at turned out to be right — here's the
  evidence to back them up in the PR.

  Method: for each release, find the newest parameter-conversion code that has
  been deleted from that branch, then work out which release first shipped that
  conversion. Any firmware older than that release loses those parameters.

  4.8 (master) → oldest 4.2
  - 94ef9886f6e / 58e5e61946d (2026-08-26) "AP_Compass/AP_AHRS: remove from-4.1
    custom-rotation conversion code" — PARAMETER_CONVERSION - Added: Nov-2021,
    first shipped in 4.2.0 (verified absent in Copter-4.1.0, present in
    Copter-4.2.0). Plus everything below.

  4.7 → oldest 4.2
  - 79e97b0864c (2025-07-16) "AP_BattMonitor: remove param conversion to dynamic
    tables required for update from 4.1 to 4.2" —
    convert_dynamic_param_groups(), absent in Copter-4.1.0, present in
    Copter-4.2.0.
  - 175e24d5140 (2025-07-22) "AP_RPM: remove param conversion from 2021" —
    AP_RPM::convert_params(), same story: first shipped 4.2.0.
  - Everything else dropped in 4.7 is pre-4.0: e202a4128cb (Copter, "all in the
    Copter-4.0.0 tag"), fadc2938675 (Plane, "all present in 4.0.0"),
    069939b87c7/7c903adff8a (Rover/Sub ARMING_CHECK, "in 4.0.0").

  4.6 / 4.5 / 4.4 → oldest 4.1
  - e8802d1858f (2023-01-03) "AP_Airspeed: remove old param conversion" — the
    AHRS_WIND_MAX → ARSPD_WIND_MAX conversion (Added: Oct-2020) first shipped in
    4.1.0 (absent in Copter-4.0.7), removed in time for 4.4. That's the binding
    constraint for 4.4–4.6.
  - 4.6 also drops 2fd10d5ff29 (Plane quadplane PIDs, "upgrading from 3.7 to 4.6
    will not work as well") — 3.7-era, doesn't move the floor.
  - Nothing removed between 4.5.7 and 4.6.3 touches anything newer than that,
    and no conversion dated after Oct-2021 is missing from 4.6.3.

  I cross-checked this two ways: ancestry of each removal commit against
  Copter-4.5.7/4.6.3/4.7.0/master, and a per-release census of every
  PARAMETER_CONVERSION - Added: <date> comment still in the tree (the only date
  that disappears 4.6→4.7 besides the 2021 ones is Feb-2022, and that's
  cef48fc432f, which removed comments that were mislabelled — they were default
  values, not conversions).

  Changes to the page: table rows for 4.5 and 4.4 added (both 4.1), and a note
  that the table gives maximum jumps, not vehicle-specific paths — which answers
  ES-Alexander's Sub point without needing [site] filtering: Sub 4.1 → 4.5 →
  4.7 falls straight out of the generic numbers.

  I didn't touch rmackay9's request to move the "Parameter Migration" section
  over to the Loading Firmware page — say the word and I'll do that too.

@peterbarker

Copy link
Copy Markdown
Contributor Author

Henry and I chatted.

We noted that there were several sections missing from one page but were present on another.

@Hwurzburg is going to make a common page to hold some of this stuff (inc. references to the custom build server IIUC)

@Hwurzburg

Copy link
Copy Markdown
Contributor

Per @rmackay9's suggestion above, the "Parameter Migration" section (prose + version table) is now carried in #8002, which collapses the two "Loading Firmware" sidebar entries into a single common-loading-firmware.rst page. It lands there as the "Parameter Conversion" subsection under Additional Information, with the wording and table unchanged.

That does leave the section in two places: common-firmware-update.rst here still has it. Whichever of these merges second probably wants it dropped from that copy — this PR would then be left with "Flying Stable ArduPilot Point Releases", which #8002 does not cover.

No files overlap between the two PRs, so they won't conflict in git either way.

Hwurzburg added a commit to Hwurzburg/ardupilot_wiki that referenced this pull request Sep 1, 2026
The setup sidebar carried two separate "Loading Firmware" entries, one
for boards that already have an ArduPilot compatible bootloader and one
for boards that do not, forcing the reader to decide which page applied
before either page explained how to tell. Both pages also carried their
own copies of the firmware download instructions and the beta/developer
version descriptions.

Add a single "Loading Firmware" page as the sidebar entry, structured as:

1. Download the Firmware - firmware server navigation, which file type
   each loading method needs (.apj / _with_bl.hex / .abin / .bin), and
   Stable, Beta, Latest Developer and Custom Builds subsections.
2. Loading the Firmware - how to tell whether the autopilot has an
   ArduPilot compatible bootloader, from the board's provenance and from
   a USB/Device Manager test, then links to the two loading pages.
3. Testing that it Worked.
4. Additional Information - Parameter Conversion, Loading Firmware via
   SD Card, and Firmware Feature Limitations with the custom build
   server.

The Parameter Conversion section takes the "Parameter Migration" text
and its version migration table from ArduPilot#7981, as suggested by rmackay9
there; the wording and the table are peterbarker's.

Retitle the two loading pages to say which case they cover, and reduce
them to just the loading procedure, with the download, beta/developer,
SD card, feature limitation and testing content now on the parent page.
Both keep their existing anchors so the many board pages that link
straight to them are unaffected.

Drop the Zadig and Betaflight Configurator alternate DFU method, leaving
STM32CubeProgrammer as the single documented path, and remove the two
images it used. The external flash/SSBL section stays, as those boards
cannot be loaded with STM32CubeProgrammer at all.

Point the cross-references that previously offered the reader a choice
between the two pages at the new page instead.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Hwurzburg added a commit to Hwurzburg/ardupilot_wiki that referenced this pull request Sep 4, 2026
The setup sidebar carried two separate "Loading Firmware" entries, one
for boards that already have an ArduPilot compatible bootloader and one
for boards that do not, forcing the reader to decide which page applied
before either page explained how to tell. Both pages also carried their
own copies of the firmware download instructions and the beta/developer
version descriptions.

Add a single "Loading Firmware" page as the sidebar entry, ordered as the
reader actually proceeds rather than as a table of contents:

1. Connect the Autopilot to the Computer - plug in over USB, without
   holding DFU/BOOT, so that the board comes up as it normally would.
2. Check What is Already on the Autopilot - the board's provenance, then
   how to read the USB device name on Windows, Linux and macOS, and what
   each result means.
3. Load the Firmware - branch to the ground station page or to the DFU
   page.
4. Test that it Worked.

Reference material that interrupted that flow - firmware server
navigation, the Stable, Beta, Latest Developer and Custom Builds
descriptions, Parameter Conversion, Loading Firmware via SD Card, and
Firmware Feature Limitations - moves to an Additional Information
section below it, and the local contents block is dropped. A ground
station downloads Stable firmware by itself, so only the DFU path and
the non-Stable builds need the download instructions at all.

The per-OS detection instructions identify the board by its own USB
product string rather than by the manufacturer, since 53 of the 464
hwdefs set their own USB_STRING_MANUFACTURER, and note that the
bootloader appends -BL or -Secure-BL-v10 to that name, though not every
board changes it.

The Parameter Conversion section takes the "Parameter Migration" text
and its version migration table from ArduPilot#7981, as suggested by rmackay9
there; the wording and the table are peterbarker's.

Retitle the two loading pages to say which case they cover, and reduce
them to just the loading procedure, with the download, beta/developer,
SD card, feature limitation and testing content now on the parent page.
Both keep their existing anchors so the many board pages that link
straight to them are unaffected. The ground station page also drops its
own "Connect autopilot to computer" section, which is now step 1 of the
parent page.

Drop the Zadig and Betaflight Configurator alternate DFU method, leaving
STM32CubeProgrammer as the single documented path, and remove the two
images it used. The external flash/SSBL section stays, as those boards
cannot be loaded with STM32CubeProgrammer at all.

Point the cross-references that previously offered the reader a choice
between the two pages at the new page instead.

Co-authored-by: Peter Barker <pb-gh@barker.dropbear.id.au>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: No status

Development

Successfully merging this pull request may close these issues.

4 participants