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. ;)

[jgromes]

All of what you describe points to a problem with meshtastic, not in RadioLib.

If you have specific examples of how I can check the SPI line, let me know

As I wrote in my previous post, and as per your own steps to reproduce this:

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

The only thing I will add is you ahve to enable RadioLib SPI debug, there's a wiki page about it.

[dima-78]

Thanks! All ok. Rebuilt the firmware with one SX1268 enabled, activated additional logging.
...
DEBUG | ??:??:?? 66 [RadioIf] Started Tx (id=0x93de52d9 fr=0xaa41ef1f to=0xffffffff, WantAck=0, HopLim=3 Ch=0x8 encrypted len=48 hopStart=3 relay=0x1f priority=10)
DEBUG | ??:??:?? 66 [RadioIf] Packet TX: 591ms
DEBUG | ??:??:?? 66 [RadioIf] 0 packets remain in the TX queue
DEBUG | ??:??:?? 66 TX IRQ triggered!
DEBUG | ??:??:?? 66 [RadioIf] Completed sending (id=0x93de52d9 fr=0xaa41ef1f to=0xffffffff, WantAck=0, HopLim=3 Ch=0x8 encrypted len=48 hopStart=3 relay=0x1f priority=10)
RLB_SPI: CMDW 0
RLB_SPI: SI
RLB_SPI: SO AC
RLB_SPI: CMDW 80
RLB_SPI: SI 0
RLB_SPI: SO AC AC
RLB_SPI: CMDW 0
RLB_SPI: SI
RLB_SPI: SO A2
RLB_SPI: CMDW 80
RLB_SPI: SI 0
RLB_SPI: SO A2 A2
RLB_SPI: CMDW 8
RLB_SPI: SI 2 76 0 2 00 0 0
RLB_SPI: SO A2 A2 A2 A2 A2 A2 A2 A2 A2
RLB_SPI: CMDW 8F
RLB_SPI: SI 00
RLB_SPI: SO A2 A2 A2
RLB_SPI: CMDW 2
RLB_SPI: SI 43 FF
RLB_SPI: SO A2 A2 A2
RLB_SPI: CMDR 11
RLB_SPI: SI 0 0
RLB_SPI: SO A2 A2 1
RLB_SPI: CMDR 1D 7 36
RLB_SPI: SI 00
RLB_SPI: SO A2 A2 A2 A2 D
RLB_SPI: CMDR C0
RLB_SPI: SI 0 0
RLB_SPI: SO A2 22 22
RLB_SPI: CMDW D 7 36
RLB_SPI: SI D
RLB_SPI: SO A2 A2 A2 A2
RLB_SPI: CMDW 8C
RLB_SPI: SI 0 10 0 FF 1 0
RLB_SPI: SO A2 A2 A2 A2 A2 A2 A2
RLB_SPI: CMDW 82
RLB_SPI: SI FF FF FF
RLB_SPI: SO A2 A2 A2 A2
DEBUG | ??:??:?? 67 [Screen] LastScreenTransition exceeded 5099ms transition to next frame
ок!

[jgromes]

Rebuilt the firmware

That's not what I wrote above - if you keep running this with meshtastic, it will be significantly harder to figure out whether this problem is in RadioLib, meshtastic or the hardware. Open the RadioLib examples, build and upload a plain SX1268 example and follow your own steps to replicate this with SPI debug enabled. Mark where exactly in the debug output the radio BUSY pin hangs.

[dima-78]

I understand everything you say perfectly well (: , but I don't have an environment set up to build custom projects for promicro nrf52840 and SX1268. It may take time while I search for all the dependencies that are needed to install the libraries and boards I need for development under nordic. I work with Meshtastic from under Gitpod because my old all code is not updated due to windows 7. If you send me a link to install my board under Arduino IDE *.json I will be grateful and will test spi. Thank you for your time. (;

p.s.
!!! I can only say that I activated RADIOLIB_DEBUG_SPI=1 in the Meshtastic config and the whole bundle worked and transmitted/received packets only when connected to USB! When powered from an external 3.3V source, the system continued to work, but it returned Critical Error#3, which clearly indicates a synchronization/timing problem in SPI, which is disguised as an activated debug!
.. and when developing, try to avoid delay and use atomic non-blocking timers!

[S5NC]

You should link to the issue you opened on Meshtastic to avoid work duplication