Ikoka Noir

Dead Ikoka, whatdunit.

The problem:

During our last AustinMesh meetup, I received a present of two dead ikokas, one Nano and one Stick. Let's start with the Nano, because it's cute. Ikoka Nano boots Meshtastic (v2.7.3). Attempting to send a message it reports "No Interface". On boot it reports it is unable to start the radio.

INFO  | ??:??:?? 3 S:B:255,2.7.4.d80dcd6af,seeed_xiao_nrf52840_e22_900m30s,vardas/meshtastic_firmware_mirror
...
INFO  | ??:??:?? 21 SX126x init result -2
WARN  | ??:??:?? 21 No SX1262 radio
ERROR | ??:??:?? 21 NOTE! Record critical error 3 at src/main.cpp:1412
...
DEBUG | ??:??:?? 3 SX126xInterface(cs=4, irq=1, rst=2, busy=3)
DEBUG | ??:??:?? 3 SX126X_DIO3_TCXO_VOLTAGE defined, using DIO3 as TCXO reference voltage at 1.800000 V

Check the obvious things first, radio (ebyte e22 900m30s) is getting power (5v) on pins 9 and 10. All grounds pins are attached to ground. No shorts between any of the pins and ground. Checked the main communication connections between Seeed nrf52 and the ebyte:

• SX126X_CS - Good
• SX126X_DIO1 - Good
• SX126X_BUSY - Good
• SX126X_RESET - Good
• SPI_MOSI - Good
• SPI_MISO - Good
• SPI_SCK - Good

Starting to look like it might be either really dead or software related. The Meshtastic and Meshcore flashers do not have an ikoka nano specific firmware. The ikoka nano github points to a dead Meshtastic specific variant. The common seeed nrf variants pin mappings do not match our board. But what does match is XIAO_BLE_LEGACY_PINOUT. Meshcore community firmware for the Nano also matches (Thanks Bill from AustinMesh!) our pin out... It couldn't be a firmware mismatch, could it?

It was a firmware mismatch

D'oh. I've flashed the Nano with a dev build of meshcore using Bill's Nano variant firmware, seems to be holding steady. I've limited the tx power to 5dBm before the amp and will let it sit in the corner and repeat my local traffic as a test.

Is it still working?

Yep, 7 days and 22 hours of continuous running, should be able to send this patient home.

Why'd you keep it so long?

User reported instability as one of the symptoms when it worked. Likely a Meshtastic firmware issue, hopefully it's been resolved in a recent version. Generally you only see instability when the nodedb is corrupted.

SoapBox

What causes NodeDB corruption

Failed writes to the storage. Writing takes a non-zero amount of power from the battery, sometimes this causes a brownout. Node reboots during a write, causing corruption.

What can you do to avoid corruption

Write less. Have more battery capacity. Refuse to write after a cutoff voltage. You can attempt to solve this in software, but these are tiny devices with unstable power.

Into the breach

Our Ikoka Stick (ver 0.2.2 according to the silkscreen), looks very similar what was happening to our Nano, with the added bonus: the I-PEX/U.FL was in rough shape. Using a small flat headed screw driver, I sculpted it back roughly into I-PEX shape before attaching a Rak pcb antenna for testing. Meshtastic firmware reports the same radio issue. I did not save the output, because I am an idiot. But trust this idiot that it looked the same.

Ok, same plan, skip the electric fault testing, find the appropriate MeshCore repeater firmware matching our pin layout and flash and configure!

...

Wait, why is the usb serial not responding? Uh oh. So, I did build this myself off the dev branch, maybe try the latest official release? Yeah, still no dice. Ok, lets try a ble companion firmware... Not showing up via bluetooth either. So flashing "works", but we're probably bootlooping when trying to load the firmware. But meshtastic worked? Let's give that another shot before digging into this deeper.

INFO  | ??:??:?? 12 SX126x init result -2
WARN  | ??:??:?? 12 No SX1262 radio
ERROR | ??:??:?? 12 NOTE! Record critical error 3 at src/main.cpp:1466

Ah, there's our old friend. Who is the idiot now!

Maybe I should look for electrical faults... So the github page for the Stick claims that it should work with the "officially supported" Seeed Xiao NRF52840 kit pins. Thankfully ndoo added a nice table for me. Pinout looks correct, so we didn't end up with a weird variant (ignoring the display i2c pins...) and I don't see any faults. Validated the radio is getting power. Hmm.

This is where it comes in handy to have a clone. I have a personal Ikoka Stick, also ver 0.2.2 according to the silkscreen. It has not yet been flashed since I haven't figured out a use for it. But flashing it with the same MeshCore repeater firmware gives me a... working repeater. Now my NRF52 is socketed, while the dead Ikoka's NRF is soldered to the board, let's do one more round of poking before we attempt to transplant the working NRF into the dead ikoka.

Working ikoka:

UF2 Bootloader 0.6.1 lib/nrfx (v2.0.0) lib/tinyusb (0.10.1-293-gaf8e5a90) lib/uf2 (remotes/origin/configupdate-9-gadbb8c7)
Model: Seeed XIAO nRF52840
Board-ID: Seeed_XIAO_nRF52840_Sense
SoftDevice: S140 version 7.3.0
Date: Nov 12 2021

Woah, wtf. While in DFU (disk emu) mode the e22 radio got stupid hot. This was my working ikoka! Thankfully the radio seems to have survived and I am unable to recreate the heating scenario. Floating pins are not a fun RNG.

Dead ikoka:

UF2 Bootloader 0.9.2 lib/nrfx (v2.0.0) lib/tinyusb (0.12.0-145-g9775e7691) lib/uf2 (remotes/origin/configupdate-9-gadbb8c7)
Model: Seeed XIAO nRF52840
Board-ID: nRF52840-SeeedXiaoSense-v1
Date: Jul 19 2024
SoftDevice: S140 7.3.0

Bootloaders seem weird, is there actually a difference between my two nrf52s? If I unsocket my nrf52, I see the same behavior. Meshcore hangs before enabling the serial console and it would obviously fail at initializing the radio if it was running Meshtastic. NSS on the failed radio mesasures 1.5v, on the radio and at the MCU. Why is that not being brought high? NSS on the unsocketed working ikoka is HIGH... ok, so short? Not shorted. I think I'm ok with calling out this NRF and unsoldering it. There is potential that it's still the radio, but I'll need to isolate the two to be see what side the fault is on on.