Does anyone have any experience with resurrecting these p1 solar nodes. I accidentally uploaded the wrong Meshtastic firmware to it (the Rak 4631 firmware was in the same folder and I accidentally moved it to the solar p1 drive after I double clicked reset). Shame on me. Now the solar P1 will just constantly reboots after about 10 seconds. When i have the solar P1 plugged into my computer i can hear the windows ding for a device connecting and disconnecting. I can still double click reset and get into the (DFU? Bootloader?) mode, and still see the drive “XIAO-BOOT”. While in this (DFU? bootloader?) mode, the rebooting every 10 seconds issue goes away. But when I drag a new Meshtastic firmware to it, I get the same issue of it rebooting every 10 seconds. I did some chat GPT research and it looks like I may have overwritten some important stuff by uploading the wrong firmware. After some trouble shooting i downloaded NRf Connect Programmer, and after messing with that for a bit and doing some research realized the issue probably cannot be resolved over USB. It is looking like i might I need to flash (via SWD with a Segger Jlink EDU mini) one or all of the following: the soft device, bootloader, and Meshtastic firmware. I have been pulling my hair out the past few hours trying to recover this and then i found these forums. I saw a forum thread here where a gentleman recommended deleting the current.uf2 and resetting, this did not work for me. Any advice would be helpful, i would assume since this device uses the NRF52840, someone may have had a similiar issue or the knowhow to help me. -Thank you Kindly.
I turned Putty on with serial connection at the com port my device is on, with a baud of 115200, and I see the output of putty looks the same every time i captured it before it reset:
//\ E S H T /\ S T / C
DEBUG | ??:??:?? 2 Filesystem files:
DEBUG | ??:??:?? 2 prefs (directory)
DEBUG | ??:??:?? 2 config.proto (168 Bytes)
DEBUG | ??:??:?? 2 module.proto (88 Bytes)
DEBUG | ??:??:?? 2 channels.proto (57 Bytes)
DEBUG | ??:??:?? 2 device.proto (126 Bytes)
DEBUG | ??:??:?? 2 nodes.proto (281 Bytes)
DEBUG | ??:??:?? 2 adafruit (directory)
DEBUG | ??:??:?? 2 bond_prph (directory)
DEBUG | ??:??:?? 2 bond_cntr (directory)
DEBUG | ??:??:?? 2 Power::lipoInit lipo sensor is not ready yet
DEBUG | ??:??:?? 2 Use analog input 16 for battery level
INFO | ??:??:?? 2 Scan for i2c devices
DEBUG | ??:??:?? 2 Scan for I2C devices on port 1
INFO | ??:??:?? 2 No I2C devices found
DEBUG | ??:??:?? 2 acc_info = 0
.
.
.(I have removed a bunch of stuff for the sake of the post not being huge, but see below lines were it fails on that last line every time)
DEBUG | 07:26:44 6 [GPS] NMEA GPS time set 2025-12-28 07:26:44 age 2
INFO | 07:26:44 6 [PowerFSM] Loss of power in Powered
INFO | 07:26:44 6 [PowerFSM] Loss of power in Powered
DEBUG | 07:26:44 6 [PowerFSM] Init NRF52 Bluetooth
INFO | 07:26:44 6 [PowerFSM] Init the Bluefru
it always fails there, and this kind of lines up with what chat GPT was pointing towards, that something might be wrong with the Bluetooth. Every time it gets to the Bluetooth initialization, it reboots.
PSA: obviously you do not want to flash the incorrect firmware to the device, but in my case seeed studio tech support was able to get me back up and running.
How did support resolve the issue?
did you open it up and press the boot and reset button on the xiao?
it doesnt look like the xiao has a boot button on it… what da?
Hi. I also got into this Boot-Loop, with the SenseCAP Solar Node P1 Pro.
After flasing MeshCore Repeater. Might also have flashed the wrong image first.
Also reboots at the same place “Init the Bluefru”
The MeshCore image is even more unresponsive, not having any terminal output.
Any ide of how to fix it?
My t1110 is now boot looping when it never did before must be xsomething in the water
Update.
Seems that the reboot is connected to TIME.
The place where it now reebots is now at “Init the Blufruit nRF52”
So it was able to print a few more caracters.
I timed the restart to about every 9 seconds.
I think there is a Hardware Watchdog enabled.
I will dig deeper into this when I have time.
Also found this issue on Meshtastic Github
Indicating it can be: brownout due to insufficient voltage during a 1W Tx
GitHub: /meshtastic/firmware/issues/7761
Have you checked if you have the exact SoftDevice and bootloader versions recommended for the Solar P1?
Hi there,
And welcome here…
So , first Point of reference. Is STOP , don’t pass go or collect $200 
If you flashed the wrong image to the unit, Unless you fully restore it, no chance of tweaking your way back.
START , there… Flash a factory image properly and Verify it is using the as delivered firmware.
Anything else , YOU are wasting your time. 
I can’t tell from the post a what point in the process you are at…?
HTH
GL 
PJ 
It’s a solar device, so the Battery charge level and solar supply will need monitored as well. 
Setting MAX power without some operational profiling first , is like what they say about Planning.
" Failing to Plan = Planning to FAIL! " 
YES… this is verymuch what my T1110 is doing… think maybe a new bootloader is in store… or a complete whipe of the flash memory
actually you are right, because now that you say this… i believe i acciently flashed the T-1000-E Firmware onto my T1110 thinking it was the old LoRa firmware, what da..
I finally got ALL 4 of my devices going ,
- T1000E
- Xiao_SX_S3 (full monty , display, push button, Battery Pack, GPS.
- Xiao_SX_S3 Vanilla w/GPS
- Xiao52840_SX w/GPS. on bottom.
All are 7.15 except the T1000E ?
More testing is Planned , seeing stuff from North East showing UP?
WOW
GL PJ ?
Just as a follow up… I have not had the time to fix this problem on my hardware but i will say this… this is the correct tide… the positive is always the negitive… the internal partition of SSD for lack of a better term, the internally accessable flash memory is differrent between units and meshtastic.. vs LoRa… I believe this is more because of sloppy and un-unified coding than design… but it was positive… because i could flash meshtastic or SenseCAP LoRa firmware without loosing my config of either system….. the problem is when you corrupt the partitions with a wrong firmware that breaks the tide… I did not understand but it appears you have to do a full wipe when you corrupt the partitions or create incompatable partitions by installing the correct firmware… i wish the code could be unified to save the best of both worlds… but it appears you must “reformat” the flash of you install the wrong firmware… just uploading a new firmware does not automaticly fix the file system errors… like i said i believe this root is a sloppy code… but i am sure someone will disagree…. I am hoping Seeed in conjunction with meshtastic developers can make the best of these two worlds..
Hello Oystein,
I contacted seeed studio tech support, explained what I did, they sent me a file to flash to my device along with some instructions.i was up and running within 15 minutes of receiving their reply. Good luck my friend.
Hello Nikita,
They sent me a file and instructions. I was actually able to solve the issue via a USB connection. I just had to run a special command (with a special library) over the command line to completely wipe the device. After device was wiped I could flash the file they gave me and then after that I could install the correct meshtastic firmware. So contrary to everything you read on the internet, flashing the wrong firmware may not always result in a complete brick of the device. Seeed studios was quick to reply and fixed the issue promptly. Kudos to them.
I was able to resolve the issue on my device. The Seed Studio SenseCAP Solar Node P1 Pro. By reflassing the Bool Loader onto the device, and then reflassing the Application firmware (Meshtastic), then the application stopped bootloop.
The process is described on the Seeed Studio Wiki at: wiki dot seeedstudio dot com /get_started_with_meshtastic_solar_node/#flash-the-bootloader
The few previous posts led me to try this procedure. So, thanks I_like_radios, cgwaltney, and PJ_Glasso.
I think what is happening is that, when we flash the wrong uf2 image, there is something that gets overwritten, maybe in the boot loader, so new attempts at flashing the Application firmware seems to fail mid way, giving a corrupt application image, again resulting in the reboot.
Note. It seems I dropped down the UF2 Bootloader version from 0.9.2 to 0.7.0 in this process. The newest bootloader can be found at GitHub adafruit/Adafruit_nRF52_Bootloader/releases
Also increase the number of hops from 3 default to 7 max and you will get more to!
Do you know how to wipe the flash memory on the Nrf?… thay make it sound so easy… but you need a j-link or something?
can you make a .df2 file that will format the memory… i downloaded the erase.df2 and it did nothing.. what da?
Hi there,
I used this UF2 file on the Github to erase the Nrf52840, for meshtastic. You drag and drop it,(too easy) it reboots and BOB’s your uncle to reflash the code for meshtastic. I had a stubborn Nrf52840 BLE that needed the Erase all Uf2 that’s there, After it programmed without issue. 
HTH
GL PJ
nrf_erase.zip (46.0 KB)