@robots, thank you very much for your work with this! It's both informative and effective!
I used the tools to back up the firmware for my DR200+ before the batteries die. Everything seems to have gone smoothly! Thanks!
Unfortunately, my CU already lost it's firmware, and while I am able to use it without, it would be nice to have it working again. I replaced the batteries successfully and everything seems OK except for missing firmware. It reads "Version 668-01.01" on the "Load program!" screen, and "668-01.01>>>64438>10553>" on the serial connection. Have you tested if it's possible to upload firmware from a different CU successfully?
Thank you very much robots. I will try to revive our old 510N.
Translated by Google:
Hello you genius!
I came across your posts in this thread. Respect!!!
You've done a lot of work, I think it's worth it, many people have already expressed their thanks.
My problem is a bit different, but I think your work will help me solve it.
I'll tell you briefly, maybe you have a solution ready right away, if not, that's not a problem.
I have a Trimble 5603 with a Geodimeter CU (ALPHA 571).
- The batteries of the 5603 have to be exchanged, I would like to do that myself, so I have to save the memory, exchange the batteries and then transfer the backup again. For this I build myself a reasonable RS232 adapter.
- The CU reports "Program Lost!" I think that's really bad. Trimble, Herzog and Allterra no longer support the CU. My only idea is to get hold of another user's backup and upload it to my CU. A reboot brings nothing - unsuccessful.
I think the main problem is that Trimble's support is purely for-profit and therefore "less social". The main thing is to sell new devices and throw away good old ones. Leica and Sokkia wouldn't allow themselves that!
You wrote that you invested a lot of time in reverse engineering. I hope you had a good disassembler handy such as IDA Pro Advanced. It's not child's play, but a good tool makes the job a lot easier.
To put it bluntly: I would like to be with you in your project?ÿ
@zeus Hi, no i dont use IDA Pro its not free, and AFAIK very hard to obtain (money is not everything).
There is problem with CU, no way to backup the firmware in reasonable way. I have few dumps from german CU. But I have no reliable way to put it back to CU.
And i dont have much time to work on this project for now. It might change soon, (or not)
he batteries of the 5603 have to be exchanged
I see too late at this point... but if the internal battery backup still has juice, is it possible to "jump" the old battery with a new one (parallel connection) to keep it "live", then remove/desolder the old battery and connect new one?
I may need to do this with an older Leica TCRA1103 Plus at some point as Leica will not do it... just like Trimble does, with these great working instruments that are still vert much valuable.
There is problem with CU, no way to backup the firmware in reasonable way. I have few dumps from german CU. But I have no reliable way to put it back to CU.
?ÿ
Hello Robots,
so, where are the Dumps from, if there is no way to Backup?
Most services in Germany told me, ??oh, oh, oh!??, that??s hard, we don??t think it will be possible to recover the software. The only choice might be to restore an existing Backup. So i habe to figutr out, if there is existing a Backup.
Interesting is, that they (say they) need the GDM too, to restore the data in ram ????...
?ÿ
Just in this moment i try to understand the memory-mapping, -segmenting and adressing of the cu1. You ??prepared?? a document like 0000:0000-0000:07FF, 0800:..., 1000:... and so on. The eprom is mapped to F000:... and F888:...
It??s hard to find the jumps and far jumps - jsr??s are not the problem.
?ÿ
Probably there is a thing like the pencil-trick, e.g. a hidden jtag, any throughpass in the gdm?!?
?ÿ
Let??s figure out ???¦
?ÿ
The next attemp is to tap the adress bus of the mcu/cpu in cu, watching the adresses and cs-signals wich are ??called?? e.g. if you decide for ??factory defaults??.
?ÿ
Sure, it??s easier to write an own software to get access to gdm with android, win10, ios, python is a good choice.
?ÿ
My Batteries were completely dead, restore factory defaults with external power: unsuccessful.
?ÿ
You??ll get mail of me ????
?ÿ
There are few good shops in germany, supporting Leica-TS for little money, one in rostock, anothermin bad vilbel, but leica, e.g. TS06 may offer a Program (import/export) to make a dump by yourself - it??s not trimble...
?ÿ
My Batteries are fine (> 3 volts), it seems, the timer is reached...
?ÿ
?ÿ
?ÿ
Hello a few years later,
I got over an old 5600 with a TSC2 and an ACU for small amount and thought it would be a nice and easy hobby project. The instrument had been standing in a shreed for almost 12 years so the internal batteries in the 5600 had most likely died. These are replaced but know comes the tricky part. The firmware is gone due to the batteries was dead, last service was done 2008.
Is there any way to upload the FW to the instrument again. when connecting the ACU onto the 5600 and trying to connect to the totalstation nothing happens, but the servo is working atleast :).
I've manage via RealTerm connect to it but only gets 30.8 as an answer (Syntax error)
Is it an impossible task or is there a way to upload the FW?
Best regards,
Rick
Thank you so much for this set of utilities!
I just backed up my Geodimeter 610 Pro (which does work!)
However, I can't seem to backup the CU Alpha that goes with (And also works!)
CU:
>?
632-05.05
>
Is there a trick? I had to remove the CU from the total station in order to get the backup to pull.
Plugging directly into the CU (with it detached from total station) starts to work but ends thus:
./backupfirmware.py /dev/ttyUSB0 savefile
cmd send: RG,127
cmd recv: 127=17334
seed 17334
key 226785
key 30177
cmd send: WG,127=30177
cmd recv: >>
Traceback (most recent call last):
File "Projects/Totalstations/Trimble/gdm/gdm600/./backupfirmware.py", line 121, in <module>
response = gdm_write('G', 127, key)
File "Projects/Totalstations/Trimble/gdm/gdm600/./backupfirmware.py", line 90, in gdm_write
return val[0]
IndexError: list index out of range
I looked in the gdm600cu folder, and I see only:
parsedump.py
and upload.py
But no download.
Also, for what it's worth, I tried pushing the GDM-610 firmware into my dead-battery 5601 and it went through the programming cycle but then just started beeping... (Of course the internal battery is still flat dead, I measured, so a simple power cycle cleared the beeping. I know this wouldn't work but hey what have I got to lose? LOL)
Thanks again and thanks for any clues!
PS/EDIT:
Ahh, I see your comment that (at the time) we don't know how to download the CU firmware.
Is there any update, or is the firmware in flash?
Does the CU go braindead if it loses battery? That wouldn't make much sense since it doesn't have calibration constants for the actual measurement hardware.. Or does it?
Just wanted to say that I too have a 5600 that says 30.8 on the serial terminal.
However, the bootloader is still in it -- if I type ? and press enter it gives me available commands:
>?
698-02.00 commands:
Load new program LV=0
Memory ASCII-hex dump OV*
GDM model RV,100
Link date/time RV,110
GDM serial number RV,111
Program version RV,113
Check RAM CRC CRC
Run loaded program RUN
Power off WV,107=1
Read RAM byte(s): MR<adr>[L<len>]
Write RAM byte: MW<adr>=<data>
Memory bank: BS[1|2|3|4|5|6|7]
List valid commands ?
>
If I tell it to run, it says this, which means checksum error:
>RUN
51.8
>
I've got an old geodimeter you'd be welcome to have if you need parts or another test subject.
I'm interested! Do you know what model it is approximately? Is it motorized?
Thanks!
I continue to tinker with these old Geodimeter units. I have a couple 610's, a couple 140's, a 4400 and a 5601.
Here's some notes in case anyone else is following this same path!
Also got a couple RMTs (the 360 and the non-360 long range) for the 600's, and one for the 4400.
The 5601 is ram bat dead, still has the boot loader in it through.
One 610 seems to work fine, except I cannot get it to communicate with my TSCe/Ranger.
The other 610 works except EDM returns random readings, but it works fine with TSCe/Ranger.
The 4400 seems to work fine most of the time except when the level compensator isn't working...
I also have two CU's -- one works with the two 610's.
The other says "Wrong device" and it's got settings in it relating to direct reflex, so I think it's for some variant that does direct reflex.
Some interesting notes -- the 610's won't let you read out their firmware unless you solve a math problem, which @robots shows in his code:
KEY=(((SEED+171)*0x0d)-780)&0xFFFF
The station gives you a seed and you do the math and give it the key and that lets you then read the memory contents in some generic HEX format that has no checksums.
Interestingly, the 5601 lets me read the memory contents without authenticating -- but maybe that's because it failed a checksum (since the battery is dead)?
As to the 610 which won't work with the TSCe/Ranger, at first I thought maybe it's swivel was just bad and there wasn't a good connection on the serial port.
However, I can read the ram backup (although I did notice it only did the first 3 banks, not all 7.)
As to the 610 with the bad EDM which does work with TSCe/Ranger, it spits out 7 banks.
But I noticed in the case of both 610's, the data is different every single time I read it. About 75 lines of hex are different. However, the raw hex dump is the exact same size and still correctly formatted so I don't think it's just corruption in transit.
< 19E0H: 31 30 0D 41 54 53 33 3D 34 0D 41 54 4B 34 04 00
---
> 19E0H: 31 30 0D 41 54 53 33 3D 34 0D 00 00 00 00 00 00
To the Unknown person offering services,
It looks like your lunar waneshaft overfumbled.
(I've been away for some time and I couldn't figure out how to just add a message to this thread, so I've done a reply to this message.)
I finally got around to using the toolkit to get a FW backup of the three instruments. Thank you very much to the OP and other P's for producing this.
My operating GDM 650 (same as 5601) looks like it has lost it's internal batteries and I get this:
PS C:UsersRichard> & C:/Users/Richard/AppData/Local/Programs/Python/Python312/python.exe c:/Users/Richard/Downloads/backupfirmware.py
c:UsersRichardDownloadsbackupfirmware.py:87: SyntaxWarning: invalid escape sequence 'd'
val = re.findall('d*.?d+', l)
c:UsersRichardDownloadsbackupfirmware.py:103: SyntaxWarning: invalid escape sequence 'd'
p, val = re.findall('d*.?d+', l)
cmd send: RG,127
cmd recv: 30.8
Traceback (most recent call last):
File "c:UsersRichardDownloadsbackupfirmware.py", line 113, in <module>
seed = gdm_read('G', 127)
^^^^^^^^^^^^^^^^^^
File "c:UsersRichardDownloadsbackupfirmware.py", line 101, in gdm_read
raise Exception("bad response")
Exception: bad response
PS C:UsersRichard>
I couldn't figure out the SEED thing in the previous posts.
I also have a 5601 which had batteries and calibration done around 2016, I think, but never really used it because the tracker is not aligned well with the scope, and it was problematic to get to run in robotic in SurvCE. However it is still "live" and I got this:
PS C:UsersRichard> & C:/Users/Richard/AppData/Local/Programs/Python/Python312/python.exe c:/Users/Richard/Downloads/backupfirmware.py
c:UsersRichardDownloadsbackupfirmware.py:87: SyntaxWarning: invalid escape sequence 'd'
val = re.findall('d*.?d+', l)
c:UsersRichardDownloadsbackupfirmware.py:103: SyntaxWarning: invalid escape sequence 'd'
p, val = re.findall('d*.?d+', l)
cmd send: RG,127
cmd recv: 127=6079
seed 6079
key 80470
key 14934
cmd send: WG,127=14934
cmd recv: >0.0>
send OV*
Reading main mem ... 7ff0 99%
Reading bank 1/8 ... fff0 99%
Reading bank 2/8 ... fff0 99%
Reading bank 3/8 ... fff0 99%
Reading bank 4/8 ... fff0 99%
Reading bank 5/8 ... fff0 99%
Reading bank 6/8 ... fff0 99%
Reading bank 7/8 ... fff0 99%
Readout done. Saving to firmware to fw.s
cmd send: WG,127=14935
cmd recv: 40.8>
PS C:UsersRichard>
I have attached the FW file.
I also have another GDM 650 which I got as a spare and never really bothered with as I had the other one working. It was probably last calibrated and batteries done in 2016 as well, and it is still operational! And I got this:
PS C:UsersRichard> & C:/Users/Richard/AppData/Local/Programs/Python/Python312/python.exe c:/Users/Richard/Downloads/backupfirmware.py
c:UsersRichardDownloadsbackupfirmware.py:87: SyntaxWarning: invalid escape sequence 'd'
val = re.findall('d*.?d+', l)
c:UsersRichardDownloadsbackupfirmware.py:103: SyntaxWarning: invalid escape sequence 'd'
p, val = re.findall('d*.?d+', l)
cmd send: RG,127
cmd recv: 127=13636
seed 13636
key 178711
key 47639
cmd send: WG,127=47639
cmd recv: >0.0>
send OV*
Reading main mem ... 7ff0 99%
Reading bank 1/8 ... fff0 99%
Reading bank 2/8 ... fff0 99%
Reading bank 3/8 ... fff0 99%
Reading bank 4/8 ... fff0 99%
Reading bank 5/8 ... fff0 99%
Reading bank 6/8 ... fff0 99%
Reading bank 7/8 ... fff0 99%
Readout done. Saving to firmware to fw.s
cmd send: WG,127=47640
cmd recv: 40.8>
PS C:UsersRichard>
I have attached the FW file.
I have three CU's and a ACU but unfortunately only one CU is operational and the ACU capitulated yesterday, so I share it around to check the instruments. I suspect the CU is on its last legs.
Very interesting reading! I went down this road years ago and wanted to just give another thought or idea that we did here with our Geodimeter. I knew getting the machine reloaded was probably not going to work out so we opened the machine, tested the two mem batts, and soldered in replacements while keeping the machine running. It is tricky work, and not for beginners. I was not able to trace all the circuits for the batt system because I was busy holding PCBs and just trying to get the job done.
If you want to protect your machine, learn where your batts are and test them. They are 3V Li batts. I could probably devise a much easier and better solution that is serviceable but again, the process was risky so I needed to get in and get out.
Does anyone have the firmware files for Geodimeter CU Alpha and a 5601 Unit?