NRF52840 promicro+SX1268 (E22-400M22S) hangs after initialization (BUSY stuck HIGH, TCXO issues, RF switch problems)

[dima-78]

We are experiencing random freezes with the SX1268 (E22-400M22S module) when using RadioLib. The module initializes successfully (sometimes after multiple attempts), but then DIO0 (BUSY) gets stuck HIGH, and the radio becomes unresponsive.

#Symptoms:
Initialization is unstable:

1. Sometimes it fails with init result -2 (both with and without TCXO settings).

2. Eventually succeeds (init result 0), but may freeze later.

3. BUSY (DIO0) stuck HIGH after some operation (TX/RX).

4. No SPI errors in logs, but communication stops.

5. RF switch (DIO2 + RXEN/TXEN) seems configured correctly, but the issue persists.

#Hardware setup:
#MCU: nRF52840.

Module: E22-400M22S (SX1268, external RF switch, TCXO).

Connections:

• DIO2 shorted to TXEN on the module.

• RXEN controlled by MCU (P0.17).

• BUSY (DIO0) → P0.29, DIO1 → P0.10, RESET → P0.09.

• SPI: Standard pins (MISO, MOSI, SCK, CS).

#Software setup:
#RadioLib (latest master/dev branch).

#Config:

• Power: Stable 3.3V (470µF capacitor added).

#define SX126X_DIO2_AS_RF_SWITCH
#define SX126X_RXEN (0 + 17) // P0.17
#define SX126X_TXEN RADIOLIB_NC // Not used (DIO2-TXEN shorted on module)
#define SX126X_DIO3_TCXO_VOLTAGE 1.8
#define TCXO_OPTIONAL

#Logs:
Module initializes after 3 attempts (fails first two times with init result -2).

After initialization, it works for a while, then BUSY stays HIGH indefinitely.

No SPI errors, but radio stops responding.

#What we’ve tried:

1. Different TCXO settings (enabled/disabled, 1.8V/3.3V).

2. Manual reset (toggling RESET pin when BUSY hangs).

3. Checked SPI signals (no visible issues).

4. Different RF switch modes (DIO2 only, DIO2 + RXEN/TXEN).

#Possible causes:

1. Race condition in TCXO startup (module needs longer delay before init).

2. SPI timing issue (nRF52840 too fast for E22?).

3. RF switch glitch (DIO2/RXEN not toggling correctly).

4. Firmware bug in RadioLib’s SX126x driver.

#Request:

1. Has anyone encountered similar issues with E22/SX1268?

2. Are there known fixes for BUSY hangs?

3. Should we add extra delays (e.g., after TCXO enable)?

4. Could this be a hardware flaw in E22 modules?

#Reproduction steps:

1. Use nRF52840 + E22-400M22S with the above config.

2. Initialize radio (radio.begin()).

3. Send/receive packets in a loop.

4. Observe random freezes (BUSY stuck HIGH).

#Additional context:

• Issue does not occur with other modules (e.g., SX1276).

• E22 works fine in standalone tests (with USB-UART adapter).

log_nrf52+e22400m22s_.txt

#firmware meshtastic:
nrf52_promicro_diy_tcxo-v2.5.0.e470619.uf2

[jgromes]

Nothing in the attached log file is from RadioLib, so I'm not sure what you expect us to do with it.

Reproduction steps:
Use nRF52840 + E22-400M22S with the above config.
Initialize radio (radio.begin()).
Send/receive packets in a loop.
Observe random freezes (BUSY stuck HIGH).

So if those are the steps, can you post the result with RadioLib SPI logging enabled? What was the SX1268 SPI command sent before the BUSY line gets stuck? You can't really expect anyone here has your specific hardware, so you will need to reproduce it using minimum code and let us know what happened.

It seems to me you have only encountered this problem with Meshtastic, what steps have you taken to rule out an issue in that codebase as opposed to RadioLib (or even as you suggest, a hardware flaw in the SX126x radio)? Or are you just posting to both repositories hoping at least one of them will do it for you? ;)

[dima-78]

You correctly noted that I posted my problem in two branches. To be fair, I checked my equipment on another Meshtastic node with esp32 + the module that I suspected was freezing (it is 100% working!) and I want to note that this freezing problem occurs specifically in conjunction with nrf52840 proMicro + lora e22 400m22s (sx1268)! which makes me suspect the Meshtastic software for this combination (nrf52840 + lora e22 400m22s). Using other firmware of different versions did not give a positive result, packet transmission stops when the module goes into transmission mode after module initialization, which is visible in the attached log. If you have specific examples of how I can check the SPI line, let me know. I built the firmware via https://meshtastic-firmware-6c1cdekm0z4.ws-eu118.gitpod.io/.. I didn't have time to check the branch in main. Setup after initializing the module, where it is possible to reduce the SPI bus speed for further tests with my equipment. ;)