* fix(nrf52): LTO was dropping the board variant's weak hook overrides
Whole-image LTO (enabled arch-wide for nrf52840 in #10655) inlines the empty
weak body of earlyInitVariant()/lateInitVariant()/variant_shutdown()/
variant_nrf52LoopHook()/variantDefault*Config() at the call site, because the
weak default and the call site live in the SAME translation unit. The strong
override in variants/<arch>/<board>/variant.cpp is then never linked, and the
board's hardware setup silently does not run.
nrf52_lto.py's -fno-lto variant recompile does not help here: the caller is the
problem, not the variant object.
Needs both ingredients, so this only affects 2.8: the earlyInitVariant()
indirection landed in #9438 and is present in v2.7.26 too, but v2.7.26 has no
-flto, so the override linked normally.
Found on the muzi R1 Neo, whose earlyInitVariant() drives DCDC_EN_HOLD (P0.13,
the DC-DC hold after the user button) and NRF_ON (P0.29, "tells IO controller
device is on"). Both were dropped from the image, so the companion MCU never saw
the nRF application come up and stayed in its DFU indication (purple LED).
Verified in the ELF: pre-fix setup() runs straight from waitUntilPowerLevelSafe()
to the LED_NOTIFICATION block with no earlyInitVariant symbol in the binary and
no pinMode/digitalWrite on P0.13 or P0.29 anywhere; post-fix it calls the real
override. HW-confirmed on an R1 Neo.
Also affected on nrf52840: earlyInitVariant() on 10 variants (incl. t-echo-card,
which sequences its RT9080 3V3 rail there), variant_shutdown() on 18 variants
(t114, t-echo, ThinkNode M1-M8, meshlink, wio-tracker-L1 ... - sleep pin parking,
so deep-sleep leakage), variant_nrf52LoopHook() on 3 RAK variants. Confirmed
dropped on heltec-mesh-node-t114 by build, not just by inspection.
Fix is __attribute__((noinline)) on both the weak declaration and definition -
the same guard already carried by loopCanSleep(), preFSBegin(), PowerHAL and
variant_enableBatteryLpcompWake(), whose comment in main-nrf52.cpp already
documents this exact failure mode.
Also extend _VARIANT_OVERRIDES in extra_scripts/nrf52_lto.py from just
_Z11initVariantv to all eight hooks. That post-link guard already had the right
logic and would have caught this on every PR - it simply was not listing
Meshtastic's own weak variant hooks, only the core's. With the list extended it
goes red on both r1-neo and heltec-mesh-node-t114 when the noinline is reverted,
and green with it. Its failure message now names both possible causes.
* review: trim the noinline rationale comments to two lines
Per AGENTS.md ("keep code comments minimal - one or two lines, max"), the
incident detail and extended background belong in the PR description, not the
source. Keeps the LTO/noinline rationale and the pointer to the guard.
---------
Co-authored-by: Jonathan Bennett <jbennett@incomsystems.biz>
* nrf52_lto: fix variant LTO exclusion (match srcnode, not mirrored path) + post-link guard
The CI-fix follow-up in #10829 anchored _is_board_variant() to
<PROJECT_DIR>/variants/ using node.get_abspath() -- but build middleware
receives nodes from the SCons variant-dir mirror, whose abspath is
$BUILD_DIR/variants/.../variant.cpp. The anchor never matched, so the
variant silently went back into whole-image LTO: the shipped ELF has
initVariant() resolved to the core's weak empty stub (bare `bx lr`),
PIN_3V3_EN is never driven, and the SX1262 probe fails with
CHIP_NOT_FOUND again -- while the build stays green, because the
post-link guard only checked IRQ handlers.
Fix: match against node.srcnode().get_abspath(), which undoes the
variant-dir mirror (the same trick piobuild.py uses for middleware
pattern matching).
Add a second post-link guard so this failure mode is a red build, not a
field failure: the linked variant.cpp.o must contain no .gnu.lto_*
sections (proves the -fno-lto recompile fired), and any override the
object defines strong (initVariant) must resolve strong in the ELF.
Verified both ways on nrf52_promicro_diy_tcxo: clean build is green with
T _Z11initVariantv and a real initVariant body in the ELF; re-breaking
the matcher turns the build FAILED with both guard checks firing.
clod helped a lot
* address comments
* nrf52_lto: defer variant CCFLAGS so APP_VERSION is present
The variant -fno-lto recompile snapshotted projenv["CCFLAGS"] inside the
build middleware, which fires during $BUILD_SCRIPT. But -DAPP_VERSION... is
appended to projenv by bin/platformio-custom.py, an unprefixed extra_script
that PlatformIO runs as a POST script -- after the middleware. The frozen
override therefore lacked APP_VERSION, so recompiling any board variant whose
variant.cpp includes configuration.h (rak_wismeshtag via sleep.h,
seeed_xiao_nrf52840_kit, seeed_mesh_tracker_X1) failed with
'APP_VERSION must be set by the build environment'.
Defer the CCFLAGS read to a callable construction variable: SCons invokes it
during command substitution, after every SConscript (post-scripts included),
so projenv now carries the version flags. -fno-lto is appended last so it
still wins over the inherited -flto.
Verified clean builds of rak_wismeshtag, seeed_xiao_nrf52840_kit, and rak4631
(regression) -- all green with the variant guard reporting the board variant
kept out of LTO.
---------
Co-authored-by: Ben Meadors <benmmeadors@gmail.com>
* Add LTO support for nrf52840 while preserving interrupt handlers
* nrf52840: enable whole-image LTO on all targets via nrf52_base
Moves -flto + the nrf52_lto.py exclusion middleware from the rak4631 env
(771018ca8) up to [nrf52_base], so every nrf52840 target inherits it.
nrf52_lto.py keeps the interrupt handlers out of LTO (framework core +
TinyUSB USBD_IRQHandler) -- they're referenced only from the asm vector
table, so whole-program LTO would otherwise drop them and the chip hangs.
HW-validated: RAK4631 (SX1262, -60KB) and muzi-base (LR1121) both boot and
init their radios. Build-verified on canaryone (fresh board, base-inherited).
Caveat: the RAK "1-Watt" variant's radio does not tolerate global-LTO
(SX126x init fails); it shares the rak4631 binary, so keep that hardware on
src-only or split it into a separate target.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* nrf52840: move -fmerge-all-constants to nrf52_base (all targets)
It had been trialed on rak4631 only; it's a general image-wide flag (the
same one stm32 uses globally, ~0.7KB), so move it up to [nrf52_base] next
to -flto so every nrf52840 target gets it instead of just rak4631.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* nrf52_lto.py: normalize path separators for Windows (Copilot review)
get_abspath() returns backslash-separated paths on Windows, so the
"/FrameworkArduino/" / "/cores/nRF5/" substring matches would miss and the
ISR-owning objects would still be LTO'd -> hang on first IRQ. Replace
backslashes with forward slashes before matching. No-op on macOS/Linux.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* Fix directory handling for LTO
* Add post-link guard to check for dropped ISR handlers in nrf52 LTO
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Jason P <applewiz@mac.com>
