firmware: replace flash.sh with a unified node + gateway flasher#160
Merged
Conversation
AI-assisted: Claude Opus 4.8
Replaces the old flash.sh, which only ever resolved the nrf52840dk path and looked for a .bin SES never emits. The gateway path mirrors dotbot device's nrfjprog sequence: recover + chiperase both cores, app then net. AI-assisted: Claude Opus 4.8
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
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.
Replaces
firmware/flash.shwith a single role-parameterized flasher for both Mari firmware roles over SWD (J-Link), and drops the old script.Why
The old
flash.shwas broken for both roles: it hardcodedapp/03app_${APP}/Output/nrf52840dk/.../03app_${APP}-nrf52840dk.bin, so (1) it looked for a.binSES never emits (linker_output_format="hex"), and (2) thegatewaypath pointed at a non-existentnrf52840dkdirectory (the gateway builds under03app_gateway_app/03app_gateway_netonnrf5340-*). Sogatewaysupport was vestigial.What it does
-f NRF52, app03app_node.-f NRF53, app core (03app_gateway_app,CP_APPLICATION) + net core (03app_gateway_net,CP_NETWORK).--buildto build the role first;--hex(node) or--app-hex/--net-hex(gateway) to supply your own images. Defaults are the role's.emProjectoutputs.noderun only touches nRF52840s and agatewayrun only touches nRF5340s; a board identified as the wrong family is skipped (use--force). The guard runs before any recover, so flashing nodes can't wipe a gateway and vice versa.--dry-runprints everynrfjprogcommand without running it.nRF5340 specifics - mirrored from
dotbot device, not hardware-verified hereThe gateway recover/program sequence (recover both cores via
CP_APPLICATION+CP_NETWORK, then chiperase+program app core then net core, in that order) mirrors PyDotBot's tested flash engine exactly. The gateway recovers on every flash by default (as PyDotBot does);--no-recoverskips it. I could only dry-run this (no gateway on the bench), so the gateway path wants a real-hardware check before we lean on it.