Support new v3 devinfo #45
Open
tridge wants to merge 3 commits into
Open
Conversation
AM32 bootloader v3 exposes a packed devinfo struct via the magic SET_ADDRESS ADDRESS_MAGIC_DEVINFO (0x23): magic1, magic2, the 9-byte deviceInfo, then length, address_shift, and four CMD_SET_ADDRESS values for firmware / filename / eeprom / tune (already >> address_shift so they fit in 16 bits). The 9-byte deviceInfo wire format from sendDeviceInfo() is unchanged, so pre-v3 bootloaders are unaffected. - FourWayIF.getInfo(): after initFlash, attempt a 27-byte read at ADDRESS_MAGIC_DEVINFO with low retries; if the magic words match, parse address_shift / firmware_start / filename_start / eeprom_start / tune_start onto McuInfo.v3. - EEPROM / file-name reads use mcu.getEepromWireAddress() / getFileNameWireAddress(), which return the v3 SET_ADDRESS values when available and fall back to per-MCU eeprom_offset otherwise. - writePages / verifyPages take physical byte offsets and convert with mcu.toWireAddress(), which honours address_shift when v3 is set; fix verifyPages indexing of `data` to use the physical byte offset (was using the wire address). - writeHex iterates from mcu.getFirmwareStartByte() to the end of the parsed-hex image (replaces the hardcoded 0x04..0x40 page range). - Add an STM32G431 MCU variant (signature 0x2b06) for pre-v3 detection; v3 values override at runtime when present. Tested end-to-end against an ARK G491 (128k, address_shift=2): firmware_start 0x1000 -> app flashed at 0x08004000, devinfo magic1/magic2 match. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
STM32 G4 (and similar) flash hardware programs in 8-byte doublewords, so the bootloader rejects a write whose length isn't a multiple of 8 with ACK_D_GENERAL_ERROR. Existing 64k AM32 ESCs happened to ship firmware that's 256-aligned, but the ARK G491 CAN firmware is 56245 bytes -> the last 56245 % 256 = 181 byte chunk failed all retries on the 4-way write. Pad the tail chunk up to the next 8-byte boundary with 0xFF in writePages(), and fix the bytesWritten accumulator to count actual chunk size (not the full step) so the UI progress bar matches reality. Matches the desktop client's behaviour (Offline-Configurator cli_main.cpp). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The bootloader CMD_SET_ADDRESS payload is a 16-bit wire address. On a 128k part (e.g. STM32G431/G491, signature 2B06) the bootloader scales that to a real flash address via (wire << address_shift), and v3 devinfo reports the shift the configurator must apply when converting byte offsets to wire addresses. Without v3, getAddressShift() returned 0 and toWireAddress() masked the EEPROM offset to 16 bits (e.g. 0x1f800 -> 0xf800). The bootloader would then decode 0xf800 with its own shift (2) to physical 0x0803e000, which is not where the EEPROM lives — a silent miscompute that could read or write the wrong flash region. Two defences: - toWireAddress() now throws if the byte offset doesn't fit in 16 bits after shifting, so any client that tries to convert an out-of-range address fails loudly. - getInfo() throws after the v3 magic-read attempt if the MCU's flash exceeds 64k and v3 wasn't populated. The configurator never supported > 64k parts pre-v3, so a missing v3 here is either a transient comms failure (user can reconnect) or an unsupported pre-v3 bootloader on a new MCU — both cases benefit from a clear error over silent corruption. Reported by codex in PR review. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This adds support for the new v3 devinfo in this bootloader PR:
am32-firmware/AM32-bootloader#68
it also fixes a padding issue on G4xx MCUs
The v3 devinfo makes us no longer dependent on the pin code to get the information we need to reliably update ESCs
I've installed this at https://am32.tridgell.net/ for easy testing