Spark PNT RTK Torch Base and Rover. LoRa firmware mismatch

Positioning and Navigation
1

I just received two Spark PNT RTK Torch models.

For a project I plan to set up a monument with known location and place one on the monument as a base when I’m out in the field with the rover.

They came with different firmware levels for all components. Call them 9DCEA and 9DAA03.
I upgraded the firmware of 9DCEA from 2.0.2 to 3.3 to match 9DAA03 shipped firmware.

Connected via bluetooth and could configure them into base and rover but would never get RTK correction. Realized LoRa firmware didn’t match. 9DCEA has 0.0.5 vs 9DAA03 with 3.0.1. UM980 firmware: 17548 for 9DCEA and 11833 for 9DAA03.

In Tera Term and Real Term can connect on Port A. Configure System->Debug hardware->STM32 direct connect for LoRa firmware upgrade. Indicates system put into direct connect mode. Disconnected Tera Term and closed it. I open STM32CubeProgrammer V2.23.0. Set Port B, Baud 5700, Parity None, RTS High, DTR High. Hit connect. Port opens, KO timeout message. Checked USB/Serial port driver CH342, updated it to 2.1.2025.7. Same behavior.

I’ve tried every combination, cycling power, RTS Low/High, DTR Low/High, Com A, Baudrates (which don’t make sense based on the chip set). Tried it with Tera term open/diconnected, open, connected.

Then I tried in both tera term and real term sending 0x7F directly after putting the Torch in pass through mode to try and initiate the wake up myself.

Same behavior with the unit that has the higher firmware value.

Can confirm using option STM32 direct connect for LoRa RX testing and STM32 dedicated LoRa TX testing that both units will transmit and receive to the terminal. Which I believe uses the same UART passthrough method as the bootloader.

Finally, attempted a powershell script to connect and send 0x7F directly while trying combinations of Rts and Dts high/low. No response from any of them.

I also used the STM32CubeProgrammer CLI to get this output:
(base) PS C:\Users\croli> & “D:\Program Files\STMicroelectronics\STM32Cube\STM32CubeProgrammer\bin\STM32_Programmer_CLI.exe” -c port=COM13 br=57600 p=NONE -vb 3

STM32CubeProgrammer v2.23.0

Serial Port COM13 is successfully opened.
Port configuration: parity = none, baudrate = 57600, data-bit = 8, stop-bit = 1.0, flow-control = off
No Init bits value is : 0

Sending init command:
#byte 0x7F sent successfully to target
Wait ends after 1 loop, dataready = 0, delay = 2007

Timeout error occured while waiting for acknowledgement.
No response from target received

Retrying UART init connection…
#byte 0x7F sent successfully to target
Wait ends after 1 loop, dataready = 0, delay = 114
Timeout error occured while waiting for acknowledgement.
No response from target received
Error: Activating device: KO. Please, verify the boot mode configuration and check the serial port configuration. Reset your device then try again…

UART PORT CLOSE

Recommendations on how to get the bootloader to connect so I can upgrade the firmware?

Also, if someone orders more than one unit your fulfillment team should try to match the firmware on them if possible. Could be an easy customer service win.

2

Hi Ryan (@Ryan_Oliver ),

This is very strange. Upgrading the STM32 is usually very straight forward…

Clicking the Torch power button would cause it to exit the STM32 pass-through mode. But I assume you’re not doing that?

If possible, can you please post a screenshot of the CubeProgrammer window, right after attempting to connect. Can you also please post a screenshot of the Windows Device Manager window, with the Ports tab open so we can confirm the CH342 Channel B COM port number.

Thank you,
Paul

3

Paul,

Thanks for the quick reply. Forum says I’m only allowed one embedded item at a time. So here is a screen shot of my response hopefully it doesn’t down size it:

Untitled
Untitled1311×3200 338 KB

Power cycled both. Reconnected via TeraTerm put it back in 17. Disconnected (did not hit power button). Then ran Com12 as shown. After failure power cycled and repeated procedure on Com13 to ensure both were done for the unit I want to update. Same behavior for the other unit. The firmware code your wrote to trigger the ESP bootloader wakeup looks right. It has me questioning if nSWBOOT0 was set but I did not select Read Unprotected it would have had to be a the factory. However, I wouldn’t expect it to be on both units since they ended up with different firmware. They are close in manufacture thought 30 serial units apart.

After this, I reconnected the terminal and hit power button to observe the terminal output:
Gibberish is probably the bootloader exiting passthrough mode.Confirmed. If I connect at 56000 and then hit the power button it is just the bootloader exiting message:

Ryan

4

Thank you Ryan (@Ryan_Oliver ),

Those screenshots are helpful.

The Torch only uses CH342 Channel B. Channel A is disconnected. So, from your screenshots, I believe you should be testing COM10 and COM12.

I’m scratching my head trying to figure this out. Maybe the fuse bits have been programmed? It seems very unlikely though. I have not heard of that happening previously.

I will mention this to Sparky later today. Hopefully he will have some ideas / suggestions.

Until later,
Paul

5

Thanks.

One more note. I tried a different laptop. 9DAA03 (the one that shipped with the updated firmware) would connect to the boot loader ins SMT32CubeProgrammer.

However, the other unit I wish to upgrade 9DCEA still did not connect.

6

Hi Ryan (@Ryan_Oliver ),

Thank you. That’s a valuable clue.

Are you connecting the Torch directly to your computer(s)? Or are you going through a hub of some kind? Are you connecting USB-C to USB-C? Please try a direct connection to a good old USB 2.0 port if possible.

Apologies for the hassle.

Best wishes,
Paul

7

Directly to computer. No hub.

I tried USB-C to USB-C using provided cable.

Tried an assortment of USB A 2.0 to USB-C cables as short as possible. Various ports on the laptop.

I don’t have a laptop with USB 2.0 ports left on it.

Ryan

8

Hi Ryan (@Ryan_Oliver),

OK. Thanks!

I spoke to Sparky about this last night and he was just as puzzled as I am.

We suspect a return may be the easiest way forward, so we can upgrade the LoRa firmware for you. BUT Sparky is away from his desk for the next couple of weeks… We may have another solution where we send you a custom firmware binary for the ESP32 which does nothing else but upgrade the LoRa. (This new code looks after the entire upgrade without needing CubeProgrammer. It’s something we’re working on building into the RTK Everywhere Firmware to save users the pain of upgrading manually.) Please leave it with us and we will get back to you as soon as we can.

Apologies again for the hassle and thanks for bearing with us,
Paul