Default settings. I even factory reset the device twice to ensure I could replicate the issue. From factory reset, you need only select profile 2, exit twice, and Torch reboots.
I have been trying to replicate this issue. I think I might have replicated it once, but I am not sure. For me, profile 2 seems to work fine - both after a factory reset and erase-flash-upload-firmware. Please see below. If you have time, please try it again.
Thank you,
Paul
LittleFS Started
Using profile #1
PSRAM Size (bytes): 2097152
I2C Devices:
0x08 - HUSB238 Power Delivery Sink Controller
0x0B - BQ40Z50 Battery Pack Manager / Fuel gauge
0x5C - MP27692A Power Management / Charger
0x60 - ATECC608A Cryptographic Coprocessor
=======================
SparkFun RTK Torch v2.1
=======================
GNSS UM980 online
Profile 'Profile2' loaded
Fuel gauge configuration complete
Charger configuration complete
UM980 configuration updated
System time set to: Thursday, March 27 2025 09:55:26
Bluetooth SPP and BLE broadcasting as: Torch Rover-32F2
STATE_ROVER_NOT_STARTED --> STATE_ROVER_NO_FIX, 2025-03-27 09:55:28.504
Batt (13%): Voltage: 6.87V Charging: 3.68%/hr
Rover Accuracy (m): 1.470, SIV: 30 GNSS State: 3D Fix
STATE_ROVER_NO_FIX --> STATE_ROVER_FIX, 2025-03-27 09:55:28.521
Tilt sensor configuration complete
Rover Accuracy (m): 1.470, SIV: 30 GNSS State: 3D Fix
Rover Accuracy (m): 1.185, SIV: 31 GNSS State: 3D Fix
Can you provide the steps you want me to follow to erase-flash-upload-firmware? Happy to capture a full log while doing it as well.
Is there a way we can dump the current contents of flash to see if something was written wrong? Seems too consistent for me, almost like a wrong bit was written to a particular register and whenever it is used, it prevents the UM980 from loading its config.
On Torch, the profiles are stored only in LittleFS (Little File System), in the ESP32 flash memory, in its own partition. The RTK Firmware Uploader has an option to completely erase the flash memory - including the LittleFS partition. This is the “nuke from orbit” option…
Unless we’ve missed something, there should be absolutely no difference between Profile2 and the other profiles… (Famous last words!)
factoryReset performs a LittleFS.format(), which should erase all of the profiles. Strictly, the erase-flash option in the uploader should be unnecessary. But it’s a useful way to ensure the profiles are truly gone, if you are unable to open the menus etc..
I don’t think there is a way to print the contents of the profile file. We should add one. It would be a useful diagnostic - especially on Torch.
Before I erase the flash, even though there isn’t a native option to read the flash from the Torch, we should be able to use esptool.py to read it. Do you have an address and size you want read? or I can just read the whole thing.
I haven’t used esptool to read the ESP32’s memory before. But it looks like you can, I see a read_flash option. The profile files will be somewhere in the LittleFS partition. It is called “spiffs” in the partition CSV:
spiffs, data, spiffs, 0xC10000, 0x370000
Start: 0xC10000. Length: 0x370000. Final address 0xF7FFFF.
If you can read that area, I guess it will contain a file allocation table telling you where Profile2 is stored.
$ esptool.py --chip esp32 -p /dev/ttyACM1 -b 460800 read_flash --flash_size 16MB 0xC10000 0x370000 torch_spiffs.bin
esptool.py v4.8.1
Serial port /dev/ttyACM1
Connecting......
Chip is ESP32-D0WDR2-V3 (revision v3.1)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None
Crystal is 40MHz
MAC: ac:15:18:00:00:00
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
3604480 (100 %)
3604480 (100 %)
Read 3604480 bytes at 0x00c10000 in 85.0 seconds (339.4 kbit/s)...
Hard resetting via RTS pin...
Remove the .pdf extension from the uploaded file. It wouldn’t allow me to upload it otherwise. torch_spiffs.bin.pdf (3.4 MB) md5sum: f03387488870bcd4d90b16ea49f0bab1