I have had 2 kits failing in the same way. I am using the kits in remote weather sensors to broadcast readings via LoRa to a central hub. For several weeks, they work fine, and then a fault appears: the software keeps running as normal, and at startup the current consumption is 19 µA. As soon as the SX1262 module has been used to send a broadcast, sleep current consumption rises from 19 µA to 5300 µA and nothing I do will reduce it. Replacing the XIAO nrf52840 board fixes the problem, but for how long?
It seems like the SX1262 is being kept awake by the nRF52840 but nothing I do will fix the problem - SPI.end(), resetting the SX1262, combinations of standby and sleep etc.
So I went back and took a look at the ping -Pong enhanced Demo after some review.
Prove whether the radio is actually asleep
After TX, issue the normal radio sleep path, then measure current. If it stays at ~5.3 mA, that strongly suggests the SX1262 never reached real sleep or was instantly reawakened. Since the module’s expected sleep current is around 1.62 µA, 5.3 mA is not a “slightly bad sleep” problem it is an awake radio problem.
Reconfigure SPI pins before MCU sleep
Don’t just call SPI.end(). Make sure the SPI pins are left in a state that cannot poke the radio awake. The Seeed forum report specifically calls out putting the nRF52840 SPI interface to sleep as necessary to avoid waking the transceiver repeatedly. So there is that along with, that stupid switch. (IMHO)
Check the antenna-switch / extra control pins
That same Seeed report notes the RF-switch pin can add current if left asserted. Not enough by itself to explain 5.3 mA, but enough to muddy the numbers and point to bad end-state pin handling.
Verify BUSY really goes idle before sleep
If code cuts corners after TX and sleeps the chip before the SX1262 is fully done, the next command sequence can get out of sync. That can leave the radio in a bad state that survives until a true hardware reset.
Use a hard radio reset test
Do a real SX1262 reset pulse, then immediately measure current before reinitializing.
If current falls back low after reset, the radio state machine was wedged.
If current stays high until the XIAO is replaced, the host pins or the XIAO hardware may be what’s holding it awake.
My best diagnosis
If I had to bet and without seeing any of the code in question, I’d bet on this:
The nRF52840 is leaving one or more interface/control pins in a state that prevents true SX1262 sleep or wakes it right back up after TX.
That fits:
the current number,
the fact that it happens after the radio has been used,
and the Seeed report about SPI needing to be put to sleep on this exact platform.
The practical fix direction
I’d steer toward:
full radio sleep command
then wait for BUSY idle
then deassert / park NSS
then set SPI pins to a benign state
then make sure any RF switch / TCXO related lines are not left enabled
then enter MCU sleep
Replacing the XIAO “fixing it” does not prove the XIAO is damaged. It may simply reset all GPIO and peripheral state back to sane defaults.
That’s the old trap with these low-power radio builds — a board swap can hide a firmware end-state bug.
I have 2 boards with identical software and bootloader and using the same SX1262 module. They behave differently. I have been through the code in detail, and with a new board the code works as it should. I wonder whether the boards are developing a hardware fault that prevents the SX1262 sleeping - a noisy bus or something?
I am using the Radiolib library, and it does most of the above. The only thing left for me to try is to disable SPI and reconfigure the pins.
Hmmm, So odd of a failure mode for me is all.
I would agree though – a noisy bus or GPIO near the ANT maybe could leave it not how it needs to be.
On a one shot test, does it go sideways current wise right away or after some delay?
Can you use the RGB LED as a Radio STATE status the Xiao is Great for this and have no USB connected?
Do the values change a little or a lot?
Stay at it, keep testing. actually it is a great troubleshooting exercise. You’ll get it sorted one way or the other, either the Hardware is BAD or something else is intermittent and sneaking in there.
Currently, it broadcasts a short data packet every 2 minutes, sleeping in between. The radio is active for approximately 4.75 milliseconds during transmission at 45 milliamps current, then listens for a short ack for up to 10 milliseconds (normally 5 milliseconds) at 5 milliamps current. The board is supplying a low current tunnel-magnetoresistance sensor as well as the on-board battery voltage divider, and has an external interrupt enabled so sleep current is just under 20 microamps.
After configuration of the XIAO nrF52840 board and SX1262 LoRa module, the device goes to sleep, waking every 2 minutes to broadcast data before going to sleep. On 2 occasions now, this has worked for several weeks before going into a state where the sleep current is 5 milliamps instead of 20 microamps. Apart from this, it continues to work as normal taking and broadcasting measurements.
The device is powered from 3 AA batteries with no USB connection.
I’ll try changing the mode of the SPI pins and also see if I can get the radio state. Even a radio reset does not help.
Thanks for your suggestions. Will report back.
Russ
EDIT:
Something else to add is that I have a sensor using a XIAO nRF52840 PLUS and this has continued to work faultlessly. This has a different board layout to the XIAO nRF52840 although the components are the same.
… whenever time is an issue you have to think of timers in the code… there is a 16bit upper limit to the units ability to count… if this is not handled correctly this can cause strange lockups
also battery power brownout can sometimes cause processing problems.. maybe try powering the device and see if the same problem happens FYI
Yes, I bought some of the kits and also some individual XIAO nRF52840 PLUS boards.
I have spent days crawling over the code and am sure that timing and logic of the main loop is fine. I also monitor the battery voltage to 0.01 V as part of the code, and it is 4.5V.
The thing is, it works fine on a fresh board and 2 boards starting working fine but both failed in the same way after several weeks.
I have just tried changing the pinMode of the SPI pins to INPUT_PULLDOWN after shutting down SPI, and that has made no difference.
Just looking at the Radiolib code now, to see what information I can extract about the SX1262 status.
Ok , Wow that is Very good Leg work on your part.
WHat frequency bands are we talking about.?
I just had a flashback of someone with these Lora boards near a cell tower and only when the co. did maintenance on a backhaul channel that the Lora was near it was cellular range EU if i recall, blew out the front ends of his RX’s or some crazy thing.
and like you it was only a certain set that was failing after some time.
I think he over came it with some shielding and some additional timing delay between RX & TX. and maybe even a band plan change away from the cellular stuff.
keep looking and Testing, you’ll get it.
GL PJ
from the PLUS working better or being immune to the HAvana-syndrome . your units are having.
Thing is nutty , it’s not a softbrick or anything to the NRF, more of the RAdio not acting right it seems. Does a manual reset of the Nrf52840 make it come back to normal sleep current the next cycle?
it is an awake radio problem.
and without seeing any of the code in question, I’d bet on this:
PJ 
.
