Hardware
Heltec MeshTower V2
Model: HT-n5262S
MCU: nRF52840
LoRa: SX1262
Version: 1W / 30 dBm
The MeshTower V2 is an outdoor solar-powered node/repeater intended for permanent installation, often in locations that are difficult to physically access.
Firmware
MeshCore Repeater:
v1.17.1-d929643
Target used:
Heltec MeshTower V2
Firmware files tested:
Heltec_tower_v2_repeater-v1.17.1-d929643.zip
and for USB recovery:
Heltec_tower_v2_repeater-v1.17.1-d929643.uf2
Request
Please add or validate OTAFIX bootloader support specifically for the Heltec MeshTower V2 / HT-n5262S.
The normal OTA process can successfully transfer firmware, but afterward the MeshTower can remain in its UF2 bootloader instead of returning to the MeshCore repeater application. This requires physical USB access to recover it, which is a major problem for a device designed to be mounted outdoors and potentially high on a pole.
Test procedure
MeshTower V2 running MeshCore Repeater v1.17.1-d929643.
Repeater operates normally and remote administration over LoRa works.
Remote reboot works correctly and the repeater returns to normal operation.
Run:
start ota
The MeshTower successfully enters Nordic DFU mode and advertises as:
TOWER_V2_OTA
On Android, use nRF Device Firmware Update with:
Heltec_tower_v2_repeater-v1.17.1-d929643.zip
Packet Receipt Notifications enabled.
PRN packet count set to 8.
Firmware transfer completes successfully.
Nordic DFU reports:
Bootloader enabled
DFU initialized
Firmware uploaded
Completed
Observed behavior after successful OTA
After the firmware upload reports Completed, TOWER_V2_OTA stops advertising as expected.
However, the MeshTower V2 does not reliably return to the MeshCore repeater application.
Symptoms:
Remote repeater administration over LoRa fails.
Both direct and flood login attempts time out.
Resetting the learned MeshCore path does not restore access.
config.meshcore.io reports command timeouts such as:
Cannot connect: Command timeout: time ...
When USB is connected, the device mounts as the:
HT-n5262
UF2 drive.
This confirms that the unit is sitting in its UF2 bootloader rather than running the MeshCore repeater application.
Recovery
The unit can be recovered by physically connecting USB and copying:
Heltec_tower_v2_repeater-v1.17.1-d929643.uf2
to the HT-n5262 drive.
After the UF2 is copied, the device reboots and MeshCore operation/configuration returns.
So the OTA firmware transfer itself appears to work correctly. The failure appears to occur during the post-DFU boot/recovery stage.
Expected behavior
After a successful OTA update, the MeshTower V2 should automatically boot the updated MeshCore repeater application and return to normal LoRa operation.
If the application firmware fails validation or boot, an OTAFIX-style bootloader should recover automatically into a usable OTA/DFU state rather than requiring physical USB access.
Why this is important
The MeshTower V2 is specifically designed as a solar-powered outdoor node.
In my planned installation, it may be mounted approximately 40 feet up a pole. Physical USB or reset-button access after an OTA problem would be impractical.
A reliable OTA recovery mechanism is therefore especially important for this hardware.
Additional observation
Remote MeshCore reboot works correctly when the repeater application is running. The problem appears specific to the boot state following a Nordic DFU firmware update.
I would be happy to test a MeshTower V2-specific OTAFIX build and provide:
bootloader version
INFO_UF2.TXT
serial logs
additional OTA test results
recovery behavior
hardware details/photos
if useful.
Hardware
Heltec MeshTower V2
Model: HT-n5262S
MCU: nRF52840
LoRa: SX1262
Version: 1W / 30 dBm
The MeshTower V2 is an outdoor solar-powered node/repeater intended for permanent installation, often in locations that are difficult to physically access.
Firmware
MeshCore Repeater:
v1.17.1-d929643
Target used:
Heltec MeshTower V2
Firmware files tested:
Heltec_tower_v2_repeater-v1.17.1-d929643.zip
and for USB recovery:
Heltec_tower_v2_repeater-v1.17.1-d929643.uf2
Request
Please add or validate OTAFIX bootloader support specifically for the Heltec MeshTower V2 / HT-n5262S.
The normal OTA process can successfully transfer firmware, but afterward the MeshTower can remain in its UF2 bootloader instead of returning to the MeshCore repeater application. This requires physical USB access to recover it, which is a major problem for a device designed to be mounted outdoors and potentially high on a pole.
Test procedure
MeshTower V2 running MeshCore Repeater v1.17.1-d929643.
Repeater operates normally and remote administration over LoRa works.
Remote reboot works correctly and the repeater returns to normal operation.
Run:
start ota
The MeshTower successfully enters Nordic DFU mode and advertises as:
TOWER_V2_OTA
On Android, use nRF Device Firmware Update with:
Heltec_tower_v2_repeater-v1.17.1-d929643.zip
Packet Receipt Notifications enabled.
PRN packet count set to 8.
Firmware transfer completes successfully.
Nordic DFU reports:
Bootloader enabled
DFU initialized
Firmware uploaded
Completed
Observed behavior after successful OTA
After the firmware upload reports Completed, TOWER_V2_OTA stops advertising as expected.
However, the MeshTower V2 does not reliably return to the MeshCore repeater application.
Symptoms:
Remote repeater administration over LoRa fails.
Both direct and flood login attempts time out.
Resetting the learned MeshCore path does not restore access.
config.meshcore.io reports command timeouts such as:
Cannot connect: Command timeout: time ...
When USB is connected, the device mounts as the:
HT-n5262
UF2 drive.
This confirms that the unit is sitting in its UF2 bootloader rather than running the MeshCore repeater application.
Recovery
The unit can be recovered by physically connecting USB and copying:
Heltec_tower_v2_repeater-v1.17.1-d929643.uf2
to the HT-n5262 drive.
After the UF2 is copied, the device reboots and MeshCore operation/configuration returns.
So the OTA firmware transfer itself appears to work correctly. The failure appears to occur during the post-DFU boot/recovery stage.
Expected behavior
After a successful OTA update, the MeshTower V2 should automatically boot the updated MeshCore repeater application and return to normal LoRa operation.
If the application firmware fails validation or boot, an OTAFIX-style bootloader should recover automatically into a usable OTA/DFU state rather than requiring physical USB access.
Why this is important
The MeshTower V2 is specifically designed as a solar-powered outdoor node.
In my planned installation, it may be mounted approximately 40 feet up a pole. Physical USB or reset-button access after an OTA problem would be impractical.
A reliable OTA recovery mechanism is therefore especially important for this hardware.
Additional observation
Remote MeshCore reboot works correctly when the repeater application is running. The problem appears specific to the boot state following a Nordic DFU firmware update.
I would be happy to test a MeshTower V2-specific OTAFIX build and provide:
bootloader version
INFO_UF2.TXT
serial logs
additional OTA test results
recovery behavior
hardware details/photos
if useful.