Trimble 4000ST Deep Dive
My notes on reverse engineering two Trimble 4000ST receivers, an 8 channel 14509-10 L1 only receiver and an 8 channel 16856-01 dual frequency receiver.
This is a work in progress.
Architecture
- CPU: 68HC000 @ 10MHz (probably 9.6f0, or 9.8208 MHz)
- Optional FPU: MC688881 @ 10MHz or 16MHz (probably 16 f0 or 16.368 MHz)
- Flash: 384 kilobytes
- RAM: 64 kilobytes
GPS Hardware - 14509-10
This receiver has an RF front end module that produces a 4.096 MHz (4f0) hard limited L1 IF signal that is fed into a Signal Processor board based on multiple Hitachi HD63C09EP (6809-like) CPUs each paired with a custom ASIC.
GPS Hardware - 16856-01
This receiver has an RF front end module that produces a 4.096 MHz (4f0) hard limited L1 IF signal, some kind of L2 IF signal, and a mystery signal. The mystery signal is fed into the PI RF board, which extracts the P-Code Q and I signals, and an SCLK(?) signal, it seems. The P-Code Q, P-Code I, SCLK, L1 IF and L2 are then fed into a board containing a TI TMS320C025 DSP in conjunction with 6 identical ASICSs.
PCBs
CPU Board
From the 14509-10:
From the 16856-01 (appears to be identical):
Carries CPU, RAM, ROM, UART, RTC, optionally a 68881 FPU, and the timing generation logic for the entire receiver.
Timing
The GPS system is constructed around a base frequency, f0, of 1.023 MHz. The L1 frequency is 1540f0, L2 frequency is 1200f0. All of the timing signals in the receiver are based off of this frequency as well. From a 6f0 clock signal generated by the from the RF module, the timing logic synthesizes 38.4f0 (192f0/5), 32f0, 16f0 and 9.6f0 clocks.
BOM
JU1 FPU Clock Select U14 HD68HC000P10 CPU U18 MC68881RC16B FPU (optional) U19 XR886681P/40 Dual UART U20 DP8570AN RTC U21 DS1211 Nonvolatile Controller U22 ADC0808N ADC U24 LH0070 ADC Voltage Reference U35 LT1039IN PORT 2 RS-232 Driver U36 LT1039IN PORT 1 RS-232 Driver X1 3.6864 MHz UART Crystal X2 32.768 KHz RTC Crystal
POWER SUPPLY Connector (P7)
1 GND 2 +5V 3 +5V Standby? 4 GND 5 -12V 6 +12V 7 GND 8 U24 Voltage Reference Input
ANALOG INPUTS Connector (P6)
1 GND 2 U22 Pin 2 (IN4) 3 U22 Pin 3 (IN5) 4 U22 Pin 4 (IN6) 5 U22 Pin 5 (IN7)
| HD68HC00010P |
SP Board (14509-10 only)
This is an interesting one because each channel has a dedicated 6809 CPU.
PI Channel Board (16856-01 only)
Memory Board
512K From the 14509-10:
1MB From the 16856-01 (same board with more sockets populated):
14509-10 CPU ROM Images
- cpu_u3.rom - Version 2.00
- cpu_u8.rom - Version 2.00
- cpu_u5.rom - Flash
- cpu_u10.rom - Flash
- cpu_u6.rom - Flash
- cpu_u11.rom - Flash
- cpu_u7.rom - Flash
- cpu_u12.rom - Flash
14509-10 CPU Combined Images
- cpu_eprom.bin - u3+u8 - boot ROM
- cpu_flash_1.bin - u5+u10 - Flash
- cpu_flash_2.bin - u6+u12 - Flash
- cpu_flash_3.bin - u7+u13 - Flash
16856-01 CPU ROM Images
Coming Soon
16856-01 CPU Combined Images
Coming Soon
Firmware Tool Image Format
256 byte header of unknown content, followed by a number of 37 byte records with a fixed format:
Byte 0-3 Address Byte 4-35 Data (32 bytes) Byte 36 Checksum
The checksum is calculated thusly:
- Add up the 8 bit values of all of the address and data bytes
- Modulus 8 the result
- Complement the result
Memory Map
The memory map is confusing. A15 on the EPROM appears to be inverted. 0x0000-0x7FFF in the EPROM maps to 0x8000-0xFFFF in the 68k address space, and 0x8000-0xFFFF in the EPROM maps to 0x0000-0x7FFF in the 68k address space.
The memory map I have deduced so far:
0x00000000 - 0x0000FFFF ROM Monitor 0x00080000 - 0x0008FFFF RAM 0x00300000 - 0x0031FFFF ROM 1 0x00340000 - 0x0035FFFF ROM 2 0x00380000 - 0x0039FFFF ROM 3 0x003C0000 - 0x3C?????? Alternate Vectors? (see below) 0xFFFF8201 - 0xFFFF823F DP8570AN RTC 0xFFFFA101 - 0xFFFFA11F XR88C681P UART 0xFFFFAA01 - Possibly front panel or keyboard
The block at 0x003C0000 is currently a mystery; some of the vectors in the vector table jump to addresses in this space. I'm assuming there is some memory mapping logic on the PCB that re-maps a portion of RAM or ROM into that address space, but I haven't figured that out quite yet.
Signal Processor
All signal processors use the same image:
sp.rom - Version 1.0
The signal processor image contains very little code. Most of the EPROM is blank, with locations 0x6000-0x6251 and 0x7FF0-0x7FFF containing any data. Presumably the rest of the firmware is loaded into RAM by the 68k on startup. At location 0x000304F8, ROM 1 contains what appears to be 2495 bytes of 6809 code, so this seems to be exactly what is happening.
DSP
Like the Maxwell receivers, the DSP has no external EPROM, so either Trimble squeezed the entire DSP firmware into the 4K ROM of the DSP, or they load the DSP firmware at boot time. I suspect the internal ROM contains a boot loader, and the rest of the firmware is loaded at power-up.
Firmware Updates
The TDUPD.EXE utility loads additional code into the receiver's RAM at 0x89000-0x8933B. This code appears to be additional functionality required to identify and program Intel flash when the receiver contains that instead of SEEQ flash.
This additional code has 4 entry points that TFUPD.EXE jumps to by calling _st_gosub:
0x89000 _test_rom_types - Flash Size Check
The 4000ST shipped with either 512kbit SEEQ flash ICs, or 1024kbit Intel flash ICs. This test compares the contents of ROM at bank_base with what can be found at bank_base+0x20000. If the system contains Intel flash, the values will be different, because the bank_base+0x20000 will be reading the upper half of the Flash memory. If the system contains SEEQ flash, the address space will roll over (because A16 is not connected), resulting in the two reads producing the same value. All three banks are tested, and a single byte is output on the serial port. The upper nibble is set to 0x04, and the lower three bits are set to describe what kind of FLASH is in each bank; 0=SEQ, 1=Intel. If all three banks are not the same, the install will fail.