nrf52: reclaim flash on the three targets nearest the warm-store cap (#11363)

* nrf52: drop BSEC2/BME68x from the three targets nearest the flash cap nrf52_promicro_diy_tcxo has been failing the nrf52_warm_region guard on develop since 2026-08-05 (image ends at 0xEA918, 2328 B past the 0xEA000 warm-store cap). rak4631 and rak_wismesh_repeater_mini are ~14 KiB clear while the nrf52 fleet drifts ~2 KiB/day, so both are close behind. lib_ignore bsec2 + BME68x Sensor library defeats BME680Sensor's __has_include(<bsec2.h>) gate, recovering ~46 KiB on each: nrf52_promicro_diy_tcxo 0xEA918 (FAILED) -> 0xDF1A8, 43.6 KiB clear rak4631 0xE6550 -> 0xDADE8, 60.0 KiB clear rak_wismesh_repeater_mini 0xE65AC -> 0xDAE64, 59.9 KiB clear This costs BME680/BME688 support, i.e. RAK1906 on WisBlock. It is a temporary measure until the environmental sensor roster is opt-in per board rather than linked into every target. rak_wismesh_pocket inherits from env:rak4631 but has ~37 KiB clear, so it is explicitly held at the nrf52 default and keeps BME680. Both lib_ignore lists extend ${nrf52_base.lib_ignore} so BluetoothOTA and lvgl stay ignored. * nrf52: give the RAK boards BME680 back, drop their Ethernet instead Excluding BSEC2 on rak4631 cost BME680/BME688 support, i.e. the RAK1906 WisBlock module - a common peripheral on the most popular nrf52 board. The Ethernet stack is the better thing to lose: RAK13800 W5100S users are served by the dedicated env:rak4631_eth_gw build, which has its own variant.h and ~163 KB clear, so the general-purpose image was carrying a networking stack for hardware almost none of its users have. rak_wismesh_pocket already set HAS_ETHERNET 0 for the same reason, so this follows an existing in-tree precedent rather than inventing one. rak4631 0xE6578 -> 0xE0D08, 35.7 KB clear (-21.6 KB) rak_wismesh_repeater_mini -> 0xE0D58, 35.7 KB clear rak4631_eth_gw -> 0xC1050, 163 KB clear (unchanged) rak4631_eth_gw_dbg -> 0xC1210, 163 KB clear That also brings rak4631 back under its declared flash budget in bin/ram_budgets.json (766,216 vs 786,000 bytes), which develop is currently failing - size-budget-gate is what has been ejecting PRs from the merge queue. mqtt/ is deliberately kept: src/mqtt/MQTT.cpp carries both the networked client (gated on HAS_NETWORKING, now 0) and the phone client-proxy path, so dropping the directory would have removed MQTT-over-phone as well. nrf52_promicro_diy_tcxo keeps the BSEC2 exclusion from the previous commit. It has no Ethernet to reclaim - nrf52_base already filters mesh/eth, mesh/api and mesh/wifi, and HAS_ETHERNET defaults to 0 - so the sensor library is the only lever there. It goes 0xEA918 (FAILED) -> 0xDF1C0, 43.6 KB clear. env:rak4631_eth_gw_dbg now extends env:rak4631_eth_gw rather than env:rak4631: it already used the gateway env's build_flags and lib_deps, and only that env still compiles mesh/eth + mesh/api. * Address CodeRabbit review comments on PR #11363 - Condense the HAS_ETHERNET comment in rak4631/variant.h to one line - Clarify rak4631/platformio.ini src-filter comment: Ethernet-free, not networking-free, since MQTT is retained - Restore custom_meshtastic_* metadata on env:rak4631_eth_gw so env:rak4631_eth_gw_dbg (which now extends it) doesn't lose the hw_model/display metadata it previously inherited via env:rak4631 --------- Co-authored-by: Jason P <applewiz@mac.com> Co-authored-by: Claude <noreply@anthropic.com>
2026-10-04 03:18:10 +10:00 · 2026-08-08 09:48:13 -05:00
parent de6b23190a
commit 5f198c44d7
4 changed files with 29 additions and 14 deletions
@@ -20,6 +20,18 @@ build_flags = ${nrf52840_base.build_flags}
 build_src_filter = ${nrf52_base.build_src_filter} +<../variants/nrf52840/diy/nrf52_promicro_diy_tcxo>
 debug_tool = jlink

+; TEMPORARY: drop BSEC2 + its BME68x driver. This image is ~2.3 KB OVER the 0xEA000
+; warm-store cap and has been failing the nrf52_warm_region guard on develop since
+; 2026-08-05. Unlike the RAK boards there is no Ethernet stack to reclaim here -- nrf52_base
+; already filters mesh/eth, mesh/api and mesh/wifi, and HAS_ETHERNET defaults to 0 -- so the
+; sensor library is what has to go. BME680Sensor is gated on __has_include(<bsec2.h>), so
+; ignoring the libraries compiles it out. Revert once the environmental sensor roster is
+; opt-in per board rather than linked into every target.
+lib_ignore =
+  ${nrf52_base.lib_ignore}
+  bsec2
+  BME68x Sensor library
+
 ; NRF52 ProMicro w/ E-Ink display
 [env:nrf52_promicro_diy-inkhud]
 board_level = extra
@@ -23,19 +23,14 @@ build_flags = ${nrf52840_base.build_flags}
  -DRADIOLIB_EXCLUDE_LR2021=1
 build_src_filter = ${nrf52_base.build_src_filter} \
  +<../variants/nrf52840/rak4631> \
-  +<mesh/eth/> \
-  +<mesh/api/> \
  +<mqtt/> \
  -<graphics/EInkDisplay2.cpp> \
  -<graphics/EInkDynamicDisplay.cpp> \
  -<graphics/fonts/EinkDisplayFonts.cpp>
-lib_deps = 
+lib_deps =
  ${nrf52840_base.lib_deps}
-  ${networking_base.lib_deps}
  # renovate: datasource=custom.pio depName=Melopero RV3028 packageName=melopero/library/Melopero RV3028
  melopero/Melopero RV3028@1.2.0
-  # renovate: datasource=github-tags depName=RAK13800-W5100S packageName=RAKWireless/RAK13800-W5100S
-  https://github.com/RAKWireless/RAK13800-W5100S/archive/1.0.3.zip
  # renovate: datasource=custom.pio depName=RAK NCP5623 RGB LED packageName=rakwireless/library/RAKwireless NCP5623 RGB LED library
  rakwireless/RAKwireless NCP5623 RGB LED library@1.0.3
  # renovate: datasource=custom.pio depName=RAK12035_SoilMoisture packageName=beegee-tokyo/library/RAK12035_SoilMoisture
@@ -68,9 +63,9 @@ build_flags =
  -DLOW_VDD_SYSTEMOFF_DELAY_MS=5000
  -DSAFE_VDD_VOLTAGE_THRESHOLD_MV=2900
  -DSAFE_VDD_VOLTAGE_THRESHOLD_HYST_MV=100
-build_src_filter = ${env:rak4631.build_src_filter}
-  -<mesh/eth/>
-  -<mesh/api/>
+; env:rak4631 no longer pulls in mesh/eth or mesh/api, so the negations that used to live
+; here are redundant -- this env now inherits an Ethernet-free src filter with MQTT retained,
+; unchanged.

 ; If not set we will default to uploading over serial (first it forces bootloader entry by talking 1200bps to cdcacm)
 ; Note: as of 6/2013 the serial/bootloader based programming takes approximately 30 seconds
@@ -290,11 +290,8 @@ SO GPIO 39/TXEN MAY NOT BE DEFINED FOR SUCCESSFUL OPERATION OF THE SX1262 - TG
 // VDD=3.3V AIN3=6/8*VDD=2.47V VBAT=1.66*AIN3=4.1V
 #define BATTERY_LPCOMP_THRESHOLD NRF_LPCOMP_REF_SUPPLY_11_16

-#if defined(WISMESH_POCKET)
+// General-purpose RAK4631 builds disable Ethernet; use env:rak4631_eth_gw for RAK13800 W5100S.
 #define HAS_ETHERNET 0
-#else
-#define HAS_ETHERNET 1
-#endif

 #define RAK_4631 1

@@ -1,5 +1,14 @@
 ; The very slick RAK wireless RAK 4631 / 4630 board - Unified firmware for 5005/19003, with or without OLED RAK 1921
 [env:rak4631_eth_gw]
+custom_meshtastic_hw_model = 9
+custom_meshtastic_hw_model_slug = RAK4631
+custom_meshtastic_architecture = nrf52840
+custom_meshtastic_actively_supported = true
+custom_meshtastic_support_level = 1
+custom_meshtastic_display_name = RAK WisBlock 4631
+custom_meshtastic_images = rak4631.svg, rak4631_case.svg
+custom_meshtastic_tags = RAK
+
 extends = nrf52840_base
 board_level = release
 board = wiscore_rak4631
@@ -40,8 +49,10 @@ lib_deps =
 ; Allows programming and debug via the RAK NanoDAP as the default debugger tool for the RAK4631 (it is only $10!)
 ; programming time is about the same as the bootloader version.
 ; For information on this see the meshtastic developers documentation for "Development on the NRF52"
+; Extends env:rak4631_eth_gw, not env:rak4631: it already takes that env's build_flags and
+; lib_deps, and only the gateway env still compiles mesh/eth + mesh/api.
 [env:rak4631_eth_gw_dbg]
-extends = env:rak4631
+extends = env:rak4631_eth_gw
 board_level = extra

 ; if the builtin version of openocd has a buggy version of semihosting, so use the external version