Cardputer ADV - Cap Lora - SX126x standby RadioLib err=-705 (RADIOLIB_ERR_SPI_CMD_TIMEOUT)

[RaymiiOrg]

I'm using Meshtastic on a Cardputer ADV with a cap lora (https://docs.m5stack.com/en/cap/Cap_LoRa-1262).

[1.973124] RLB_DBG:
RadioLib Info
Version:  "7.5.0.0"
Platform: "ESP32"
"Feb  1 2026" "19:38:25"

It keeps randomly rebooting due to an assert on the error code:

[351.059009] RLB_DBG: GPIO pre-transfer timeout, is it connected?
[351.059196] RLB_DBG: -705 at .pio/libdeps/m5stack-cardputer-adv/RadioLib/src/Module.cpp:251
[351.059457] RLB_SPI: CMDW      0
[351.059543] RLB_SPI: SI
[351.059603] RLB_SPI: SO        D2
[352.059007] RLB_DBG: GPIO pre-transfer timeout, is it connected?
[352.059186] RLB_DBG: -705 at .pio/libdeps/m5stack-cardputer-adv/RadioLib/src/Module.cpp:279
ERROR | 17:57:49 352 [RadioIf] SX126x standby RadioLib err=-705

assert failed: void SX126xInterface<T>::setStandby() [with T = SX1262] SX126xInterface.cpp:276 (err == RADIOLIB_ERR_NONE)

Or another one:

INFO  | 18:11:13 267 [GPS] GPS power state move from HARDSLEEP to ACTIVE
[277.349010] RLB_DBG: GPIO pre-transfer timeout, is it connected?
[277.349215] RLB_DBG: -705 at .pio/libdeps/m5stack-cardputer-adv/RadioLib/src/Module.cpp:251
[278.349008] RLB_DBG: GPIO pre-transfer timeout, is it connected?
[278.349163] RLB_DBG: -705 at .pio/libdeps/m5stack-cardputer-adv/RadioLib/src/Module.cpp:251
[279.349005] RLB_DBG: GPIO pre-transfer timeout, is it connected?
[280.349005] RLB_DBG: GPIO pre-transfer timeout, is it connected?
[281.349005] RLB_DBG: GPIO pre-transfer timeout, is it connected?
[281.349160] RLB_DBG: -705 at .pio/libdeps/m5stack-cardputer-adv/RadioLib/src/Module.cpp:307
[282.349008] RLB_DBG: GPIO pre-transfer timeout, is it connected?
[282.349154] RLB_DBG: -705 at .pio/libdeps/m5stack-cardputer-adv/RadioLib/src/Module.cpp:251
[282.349254] RLB_DBG: -705 at .pio/libdeps/m5stack-cardputer-adv/RadioLib/src/modules/SX126x/SX126x.cpp:601
ERROR | 18:11:28 282 [RadioIf] Ignore received packet due to error=-705 (maybe to=0xffffffff, from=0x75ee2178, flags=0x63)
DEBUG | 18:11:28 282 [RadioIf] Packet RX (noise?) : 231ms
[282.352853] RLB_SPI: CMDW      0
[282.352960] RLB_SPI: SI
[282.353009] RLB_SPI: SO        D4
[283.353003] RLB_DBG: GPIO pre-transfer timeout, is it connected?
[283.353162] RLB_DBG: -705 at .pio/libdeps/m5stack-cardputer-adv/RadioLib/src/Module.cpp:279
ERROR | 18:11:29 283 [RadioIf] SX126x standby RadioLib err=-705

assert failed: void SX126xInterface<T>::setStandby() [with T = SX1262] SX126xInterface.cpp:276 (err == RADIOLIB_ERR_NONE)


Backtrace: 0x403782ea:0x3fcebed0 0x4038187d:0x3fcebef0 0x40388121:0x3fcebf10 0x4205784a:0x3fcec040 0x42057985:0x3fcec060 0x42056799:0x3fcec0a0 0x42056a00:0x3fcec0d0 0x4207a3e6:0x3fcec0f0 0x4207a3f6:0x3fcec110 0x4207a3b6:0x3fcec130 0x4205ab25:0x3fcec150 0x4201a6d5:0x3fcec1a0
  #0  0x403782ea in panic_abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp_system/panic.c:408
  #1  0x4038187d in esp_system_abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp_system/esp_system.c:137
  #2  0x40388121 in __assert_func at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/newlib/assert.c:85
  #3  0x4205784a in SX126xInterface<SX1262>::setStandby() at ??:?
  #4  0x42057985 in SX126xInterface<SX1262>::startReceive() at ??:?
  #5  0x42056799 in RadioLibInterface::onNotify(unsigned int) at ??:?
  #6  0x42056a00 in non-virtual thunk to RadioLibInterface::onNotify(unsigned int) at ??:?
  #7  0x4207a3e6 in concurrency::NotifiedWorkerThread::checkNotification() at ??:?
  #8  0x4207a3f6 in concurrency::NotifiedWorkerThread::runOnce() at ??:?
  #9  0x4207a3b6 in concurrency::OSThread::run() at ??:?
  #10 0x4205ab25 in loop() at ??:?
  #11 0x4201a6d5 in loopTask(void*) at :?

In the docs I can see this is SPI related: https://jgromes.github.io/RadioLib/group__status__codes.html#ga72b849c71b8fdf112d318518a3b1ac7d

A few lines later this is stated:

Often this means that the module is trying to use TCXO while XTAL is connected (or vice versa). Make sure your crystal setup (e.g. TCXO reference voltage) matches your hardware by setting "tcxoVoltage" to 0 when using XTAL module, or to appropriate value when using TCXO module

The reference examples here: https://docs.m5stack.com/en/arduino/projects/cap/cap_lora868 - use a TCXO of 3.0, my code tried both 1.8 and 3.0, but no luck.

The reboots seem random, not really reproducable regarding a specific action. With wifi, without wifi, gps enabled, disabled, etc. I have two separate cardputers with two different hats, both have this issue.

I'm not that familiar with both codebases (meshtastic or radiolib), so I'm looking for a few pointers in the right direction to debug this further.

[jgromes]

-705 is RADIOLIB_ERR_SPI_CMD_TIMEOUT, and as the debug prints show, this timeout happens when waiting for the BUSY pin of the SX126x to go low before sending an SPI transaction. Some more information can also be gained by the first byte being returned by the radio, which is 0xD2 in the first case and 0xD4 in the second. Both times the radio is in Rx mode, the second time it even has some data that can be read from the FIFO. In any case it is not related to the oscillator selection or voltage, as the radio would not have been able to start at all if that was the case.

So the question now is why is the busy pin high at this point. According to the datasheet, there should be two cases when busy can be high in Rx mode:

1. When Rx is still starting up and the radio is not yet ready to receive data
2. When the radio is processing some interrupt

In either case I would not expect the busy timeout of 1000 ms to safely cover all of that. Can you find out what operations are preceding those calls that fail with -705? My guess is that it is a standby call while the radio is in Rx, but it needs to be confirmed. Unforuntately I am not familiar with internals of Meshtastic either.

[RaymiiOrg]

I think I figured it out. The setup guide I used said to configure pin 6 as gps en pin. And you guessed it, thats wrong, thats the lora busy pin.

While compiling with as much as possible disabled, the problem didn't occur. Then, enabling modules one by one and testing, it still didn't occur until I enabled GPS. Which made me revisit the settings.

With that pin setting removed, the problem doesnt occur anymore.

Thanks for your thoughtful repy and help!

[jgromes]

That's great, I'm glad you were able to figure it out - good job! :)