"Debugging" M7100 IP and other Hillary, Patti and TMS320 based radios

[RandrewThomas]

I hope to keep this thread focused on information discovered about the internal operations of the processor hardware and firmware in the above radios.

In this post I'll try to outline the tools and methods I've used to discover things. I'll probably have to come back and edit this post or add new posts with new or correcting information.

1) I've limited my testing to Flash ROM binaries compatible with the R18 (last) version of the "ProGrammer" software since apparently RPM (which replaced it) is keyed software only available to paying users.

2) For standalone radios that you got used without a display (Control Unit), there's a fair chance it won't wake up with just battery power. You'll need to apply 12VDC to the ignition signal in this case OR you can open the cover over the processor board, find the only switch on an edge of the PCB and slide it to the position marked on the silkscreen. This will allow the radio to turn ON via a front panel CU that you may have added without having to raise the Ignition pin on the back of the radio (37 pin D connector, pin 10, I think).

3) P1 - 37 pin D connector pinout (pins that I care about):

1 - GND
2 - RS-232 Rx
3 - RS-232 Tx

4 - RS-485+
5 - RS-485-

6 - CTS - (I haven't actually needed this yet)

8 - FPROG - connect this to +12V before / during power-on to get radio in ProGram mode

18 - SPKR1
19 - SPKR2

20 - RTS - (I haven't actually needed this yet)


4) HDT (Hex Debugging Tool) - a tool in firmware that can be enabled by the FCC Menu. To enable it, first use ProGrammer (or RPM I suppose) to add "FCC Menu" to your radio's Menu button list. Then with the radio powered up, using its CU, navigate to the FCC Menu, scroll to "HDT" and change it from OFF to ON. After that, every time the radio is powered up, the HDT will use the RS-232 port at 19200 baud, N 8 1, to let you play around in the firmware's guts. It does not support breakpoints but does allow viewing memory values and disassembling H8 code. Warning: there are some bugs in its disassembler, a few instruction mnemonics showed incorrectly.

5) The RS-485 port is used to communicate with Control Units (CUs for "head units"). If you attach a decent RS-485 adapter (that auto-controls its transceiver) you can observe the CU communication protocol. Also 19200, N 8 1

6) Communication protocols, both ProGrammer and to CUs: Packet oriented where packets are encapsulated with ASCII escape code DLE (10h) and codes like SOH (01h) and ETX (03h). Packets are ended with DLE and ETX or ETB (17h) followed by a 2 byte CRC for the packet.

More to follow as time allows.

 

[RandrewThomas]

Memory mapped peripherals of the H8 "Hillary" processor:

1) appear to be mapped in the address space from 00A00000 to 00A000FF
2) peripheral at 00A0001C appears to be a 32 bit up-counter that's being used as a timer. I don't know the timebase, but suspect it would be milliseconds or microseconds. It's used in the code to measure elapsed times for a variety of things.

 

[EricCottrell]

Hello,

00A0001C is likely the "Main Clock" register in this diagram.

https://fcc.report/FCC-ID/OWDTR-0014-E/181488.pdf

73 Eric

 

[RandrewThomas]

Sweet! And thank you, that diagram helps a lot.

It looks like pot luck as to what documents and diagrams they brought to the FCC for different radios and I never thought to look for Jaguar docs.

 

[RandrewThomas]

The Hex Debugging Tool (HDT) has bugs, so be careful examining code it generates.

1) The disassembler does not decode the opcodes 01 00 78 [ERs]0 6B 2[ERd] 00 [24 bit offset from src register] ... correctly. They should decode to:
MOV.L @(d:24,ERs),ERd
but instead they decode to:
MOV.W @[24 bit offset],ERd

2) MOV.W instructions loading from a 16 bit register to a memory address pointed to by a 32 bit register aren't shown correctly. For example what should be shown as "mov.w r3,@er2" is instead shown as "mov.w r3, er2" as if it's loading a 16 bit register value into a 32 bit register.

The reverse direction is shown correctly (e.g. "mov.w @er2,er3")

Pretty sure there are other bugs in the disassembler (and probably elsewhere in HDT), so just be wary.


On the timer/counter at 00A0001C: It appears to be ticking by 10 usec (microseconds). That would be Main Clock divided by 192.

 

[merlin]

I suffered a fatal system crash 6/23, meaning re-installing windows. at least I had the foresight to keep stuff backed up. So getting back into things.
As for the HDT code, it should match any respectable H8 disassembler. The H8 datasheet and programming reference outline the memory map. Go by that info, not what you think it might be.
Remember you are dealing with embedded and any 'data' can be anywhere in the code. A lot of places in the dump for that.
As soon as I recover from the crash, I will have more detail for you.
My method is taking the flash chip, reading it, then go to work with IDAPRO. ( the entire flash)
I am compiling all the CAN/commands and responses with a port logger.(still work in progress.)
Keep at it.
73s

 

[merlin]

MOV.L @(d:24,ERs),ERd
but instead they decode to:
MOV.W @[24 bit offset],ERd
Really is the same thing, just the mnemonics are slightly different. MOV L = move long (2 bytes) MOV W=mov wide (2 bytes)

 

[merlin]

The main difference between 700P and M7100 is 'Patti' is more like 'Hillary' and includes a DSP . functionally similar though.

 

[RandrewThomas]

Thanks for the info.

The Hillary processor is an H8 300H core, apparently, but they don't seem to be using a standard memory map. But the instruction set and general registers do appear to match the 300H tech docs well.

I've wasted too much time manually examining disassembled code already, so I've bit the bullet and started writing an H8-300H emulator with Hillary specific emulation as needed. It'll probably be at least a week before I have anything to show of that.

 

[merlin]

More.

Thanks for the info.

The Hillary processor is an H8 300H core, apparently, but they don't seem to be using a standard memory map. But the instruction set and general registers do appear to match the 300H tech docs well.

I've wasted too much time manually examining disassembled code already, so I've bit the bullet and started writing an H8-300H emulator with Hillary specific emulation as needed. It'll probably be at least a week before I have anything to show of that.

Yea, doing that manually is painstaking and time consuming. Most of what I do is finding where all the bits and pieces like personality, tracking, and encrypted features mesh into the code. There is a copy of the E2prom in there also.
What I find for the mapping much matches the H8.
An emulator would be a great tool for this stuff.

 

[RandrewThomas]

H8 / M7100 emulator is taking shape. Only have about 280 of ~300 instructions left to emulate But a fair amount of background code is in place, just down to the nitty gritty of instruction execution. Once that's in place, I'll add a few more planned features and add in radio-specific emulation things as I can figured them out.

Screenshot:

 

[merlin]

Hey, that is looking good.

 

[RandrewThomas]

Options when the radio is started up in "Programming" mode as you would do to use the applications Radio Manager, ProGrammer or RPM:

Info: In programming mode the radio initializes its RS-232 port to 9600 baud and waits for characters received. Apparently the other, RS-485, port can be used too/instead, but I don't yet understand how the bootloader ROM code gets the signal from the outside to use that port.

Commands accepted via serial port:

S3 - switch to 38400 baud
Raaaaaacccccc - Read from radio. Where 'aaaaaa' is a 3 byte address in H8 memory and 'cccccc' is a 3 byte, byte count to be read.
[aaaaaacccccc - Write to radio. Where 'aaaaaa' is a 3 byte address in H8 memory and 'cccccc' is a 3 byte, byte count to be written.
Jaaaaaa - Jump to execute at memory address 'aaaaaa'

Any characters or sequences sent to the radio besides those above are errors to which the radio sends "e2" for each bad character.

The bootloader code that supports the above commands seems to be in mask-programmed ROM, so they should work no matter what Flash ROM version the radio is running.

I don't think reading EEPROM contents out to the serial port is supported since this code only returns values accessible in the normal H8 processor memory map. The EEPROM is on the I2C bus. This bootloader code can't change Flash ROM code, but can run it with the 'J' command.

The '[' and 'J' commands could be (and probably are) used to load code into RAM and execute it. The 'R' command could be used to read back uploaded code for verification (there is no handshake or error checking in the '[' upload).

 

[merlin]

That first bootloader is OTP or masked into 'Hillary' sort of like BIOS in a PC. You have to remember this is a custom made ASIC and not a plain jane H8. "Patti" is not much different but is a bit the same as generic STS320. Again, a custom made ASIC.
Reason the memory map looks strange is the haphazard way the firmware loads into ROM.
I am just now getting back from my crash, really haven't had much time to put into this.
I still need a different prom programmer that will read the chip from the 7100ip.
I have the full dump from a jaguar 700P. (nearly identical)

 

[merlin]

Power up in program mode, the hard firmware accesses the 'app command' part of firmware. That starts the command processing and enables the RS232/RS448 (these work identical) initialized at the start of app command to max baud.
That OTP rom in low memory has already done its thing. Then passes control to firmware in upper memory.
It has already initialized 'Patti' also.
Depending on radio and firmware, the display may be blank or indicate programming mode.
Host to radio [set max baud rate] > radio to host [responds with new rate] then waits for next command.
It is all in firmware, the initial 9600 setting done by the hardwired code in 'Hilary'.
The RS448 is TTL and used by external data transfer like to 'firecom'.
PS: there is a copy of EEPROM in firmware, done during programming.