Flash a bricked RAK4631 using RAKDAP1

Arduino BSP / MacOS

I have bricked a few 4631’s doing a BLE DFU (recently the tablet overheated mid-update). I’m using the RAK19011 with the 19016 power board, so no USB on the board. Usually I can also flash using pyocd and the RAKDAP1, but this doesn’t work when the device is bricked from a failed DFU.
I have tried doing a pyocd erase --chip -t nrf52840 followed by a pyocd flash -t nrf52840 "~/Downloads/s140_nrf52_6.1.1_softdevice.hex" and a pyocd flash -t nrf52840 wiscore_rak4631_board_bootloader-0.4.3.hex hoping it would reboot into BLE mode, and I could reinstall my firmware either using pyocd or BLE DFU, but no luck.
I looked at the full WisCore_RAK4631_Board_Bootloader.hex, but this appears to be for version 0.4.2, and flashing this with pyocd didn’t work.
I managed to recover one device by removing the 4631 and adding it to a board that has a USB port, but this isn’t really feasible for firmware upgrades in the field.
Am I doing something wrong, or have I missed something?

As the nRF52840 is setup for a single-bank flash memory map, an upgrade over BLE is always risky, as you experienced.
However, after a failed update over BLE, the bootloader and softdevice are still on the device and the only thing you have to flash over USB or RAKDAP1 is the firmware, not the bootloader or softdevice.

Hmm … that doesn’t work for me. I notice that the flash doesn’t delete / write anything when I reflash the application:

pyocd flash -t nrf52840 tc34_firmware.hex
0001440 I Loading /Users/ja/Documents/PlatformIO/Projects/LoRa Test/firmware/tc34/tc34_firmware.hex [load_cmd]
[==================================================] 100%
0010785 I Erased 0 bytes (0 sectors), programmed 0 bytes (0 pages), skipped 266240 bytes (65 pages) at 28.80 kB/s [loader]

Unless I do a full chip erase.