HAI Omni engineer/developer thread

[bluelake321]

	JP10	JP15	Note
EPROM	OPEN	OPEN	Enable lines always conneced to socket pins.
EEPROM	SHORT R	SHORT	Connects enable line from EPROM to EEPROM
COPY	SHORT L	OPEN	Connects Program EEPROM enable pin to Language enable pin presumably to allow copying from EPROM to EEPROM (recovery).
JP10 connects the code EEPROM enable line to the Code EPROM enable line (Jumper Right) or the Language EEPROM enable line (Jumper Left)
JP15 connects the Language EEPROM enable line to the Language EPROM enable line. It is presumed this should not be shorted if JP10 is jumpered left.

 

[bluelake321]

TP	Value	Location
TP1		By expansion port
TP2		Below expansion port
TP3		By expansion port
TP4		By expansion port
TP5		By expansion port
TP6		By expansion port
TP7		Left of DSP
TP8
TP9		Below right side of expansion port
TP10		Below right side of expansion port
TP11
TP12	+5.0 VDC	Above Program Memory
TP13	+3.3 VDC	Top Right
TP14	~5.0 VAC	Top Right
TP15	+1.8 VDC	Top Right
TP16	+12 VDC	Bottom Right of board
TP17	-10 VDC	Top Right

 

[bluelake321]

Connector	Name	Details
J8	Hardwired Expansion Bus
P1	Chip Enable 1	Marked "Address 1" - One of four chip enable lines.
P2	Chip Enable 2	Marked "Address 2" - One of four chip enable lines.
P3	Chip Enable 3	Marked "Address 3" - One of four chip enable lines.
P4	Chip Enable 4	Marked "Address 4" - One of four chip enable lines.
P5	Data TX
P6	Data RX
P7	Clock
P8
P9
P10
P11
P12
P13
P14	Ground
P15	+12 VDC
P16	+12 VDC
P17	Ground
P18	Ground
P19	Ground
P20	Ground
J9	2-Way Voice Module
P1	Ground
P2
P3	+12 VDC
P4	Ground
P5
P6
P7
JPM	Processor Debug
P1	BKGD/(TAGHI)
P2	Ground
P3	N/C
P4	(Reset)
P5	N/C
P6	+5 VDC
JPD	DSP Debug?
P1
P2
P3
P4	Ground
P5
P6	Ground
P7
P8	Ground
P9
P10	Ground
P11
P12	Ground
P13
P14

 

[bluelake321]

Comparing 4.0b. EPROM contents show up on EEPROM starting at offset 0x00300000
Memory Map
Address	Contents
0x0000 - 0x000F	0xFF
0x0010 - 0x001F	0xFF
0x0020 - 0x002F	???
0x0030 - 0x003F	EPROM Image

 

[dan_n]

That's fantastic info @bluelake321 , exactly what I was hoping to collect in this thread. Thank you.

 

[dan_n]

I updated post #8 with a new MODA pulldown location that more reliably lets a debugger reset the cpu into Special Single mode for dumping internal EEPROM.

Now I'm mainly working on the telephone circuits. If anyone has traced out the signal paths, on/off hook detect, ring detect, etc. please post a schematic or notes in this thread.

 

[bluelake321]

I updated post #8 with a new MODA pulldown location that more reliably lets a debugger reset the cpu into Special Single mode for dumping internal EEPROM.

Now I'm mainly working on the telephone circuits. If anyone has traced out the signal paths, on/off hook detect, ring detect, etc. please post a schematic or notes in this thread.

Thanks for updating that.

At this point in time, what are your specific goals in reverse engineering?

If I had the skill set, mine would be:

• Ability to dump and upload eeprom within the MCU to change board type, reset codes, etc.
• Reverse the main flash to enable updating code, adding and deleting features, etc.
• Reverse console bus to enable making replacement consoles, new 3rd party integrations, etc, via RS485.
• Get or reverse code base for android based OmniTouch7 touchscreens to allow 3rd party replacements.
• Get or reverse code base for snaplink to extend lifecycle of this software for remote access.

 

[dan_n]

I've been busy with other projects but did finally trace out the phone circuit on my OmniPro II (schematic attached). There's not much in the audio path to go wrong. Besides a bad capacitor or leaky transistor/protection-device, the only thing is audio codec U3.

 

[dan_n]

I made a cheap alarm central station receiver emulator that lets me test the HAI panel phone circuit on my lab bench. When the panel dials out, the emulator sends a handshake, the panel sends its contact ID report and gets an acknowledge handshake (kissoff). I can see every digit it sent on my Windows laptop and measure signal levels/distortion with my instruments.

I based mine off this really cool project that does it with an old MagicJack + RaspberryPI running Linux, but that is way more complicated with notification reports and alarm control over ethernet. Mine is just a MagicJack A921 connected to a Windows laptop.

WARNING: Although his project describes using an original silver MagicJack, there were several production runs where all the later ones used a different chip that doesn't work with his code. All of the A921 silver MagicJack listed on Ebay use the newer chip (Tiger580) while his had the Tiger560B. Once I figured out which chip it used (nearly impossible) I was able to find a datasheet and get it working with much simpler code (1 file, 200 lines).

One thing I learned from this is the TEST CODE for AUTOMATIC TEST TIME doesn't do anything at least for Contact ID. I captured test calls with TEST CODE set to default 98 and also set to 53 and the same Contact ID string was sent for both: 5554181602000008

 

[dan_n]

The DSP is the last subsystem to document. It handles voice messages, dial and DTMF tone generation/decoding, ContactID reporting, etc.

The TMS320VC5402 dsp chip is not connected to any external memory but has an internal RAM and ROM. It's extremely unlikely that HAI ever used enough chips to qualify for custom mask-programmed ROM so I believe the ROM only has the default bootloader and lookup tables. Communication with the CPU is over an 8 bit Host Port Interface (extended HPI8).

The dsp pins are configured to boot using the bootloader to load program code over HPI8 into internal RAM (MP/MC_ pin tied to ground, HINT_ tied to INT2_ ). I did a bus capture at startup and recorded the cpu reading the dsp program code from the firmware memory (addresses B0010-B2B7F in 4.0b OP2) and writing it to the dsp. Same for any voice message or tone data.

The cpu accesses the dsp using chip select CS0 memory space at addresses 0200-02FF. All dsp read/writes are 16 bits over an 8 bit bus so there are always 2 transfers. Only 4 addresses are used:

cpu address	dsp register
0200	HPIC (control)
0202	HPID (data read/write with HPIA autoincrement)
0204	HPIA (internal memory address for data read/write)
0206	HPID (data read/write with no change to HPIA)

This table shows the pins used by the HPI8 bus to communicate with the CPU (U59 is an extra data bus buffer only on newer rev boards):

DSP pin	buffer / translator	CPU pin
HD7 (6)	<-> U23.3, .21 <-> U59.10, .14	DATA15/PC7 (35)
HD6 (135)	<-> U23.4, .20 <-> U59.	DATA14/PC6 (34)
HD5 (124)	<-> U23.6, .18 <-> U59.	DATA13/PC5 (33)
HD4 (120)	<-> U23.8, .16 <-> U59.	DATA12/PC4 (32)
HD3 (95)	<-> U23.10, .14 <-> U59.	DATA11/PC3 (31)
HD2 (81)	<-> U23.9, .15 <-> U59.	DATA10/PC2 (30)
HD1 (69)	<-> U23.7, .17 <-> U59.4, .20	DATA9/PC1 (29)
HD0 (58)	<-> U23.5, .19 <-> U59.3, .21	DATA8/PC0 (28)
HCNTL1 (46)	<- U24.16, .4	ADDR2/PB2 (54)
HCNTL0 (39)	<- U24.17, .3	ADDR1/PB1 (53)
HBIL (62)	<- U24.18, .2	ADDR0/PB0 (52)
HR/W_ (18)	<- U24.13, .7	R/W_ (38)
HCS_ (17)	<- U24.15, .5	PF0/CS0_ (68)
HDS1_ (127)	<- U24.12, .8	ECLK/PE4 (48)

 

[bluelake321]

The DSP is the last subsystem to document. It handles voice messages and DTMF tone generation/detection, ContactID reporting, etc.

The TMS320VC5402 dsp chip is not connected to any external memory but has an internal RAM and ROM. It's extremely unlikely that HAI ever used enough chips to qualify for custom mask-programmed ROM so I believe the ROM only has the default bootloader and lookup tables. Communication with the CPU is over an 8 bit Host Port Interface (HPI).

The dsp pins are configured to boot using the bootloader to load program code over HPI into internal RAM (MP/MC_ pin tied to ground, HINT_ tied to INT2_ ). That means the cpu reads the dsp code from somewhere in the 2 EPROM (or NOR flash) chips and sends it to the dsp. Same for any message or tone data.

It's amazing work, and I would like to contribute if I can. Again, what is your goal with all of this reverse engineering? Build a modern board? Just document stuff for repair?

 

[dan_n]

It's amazing work, and I would like to contribute if I can. Again, what is your goal with all of this reverse engineering? Build a modern board? Just document stuff for repair?

My goal is to enable the same level of repair support (by others with an LLC) that HAI/Leviton used to offer. Right now I can unlock a panel or replace any part including the cpu which requires EEPROM programming.

I'll stay away from modifying firmware since this is a life-safety device. Decoding protocols for automation devices is okay but I'll stay away from related life-safety things like wireless receivers, etc. However if anyone else works on those things feel free to post it here.

 

[dan_n]

This thread needs at least one firmware disassembly listing.

The attached file shows the firmware code (4.0b chip) that writes 1 byte into the cpu internal EEPROM and gives an idea of what's involved in writing that EEPROM. I couldn't find a separate hw bulk erase subroutine so they must call this routine 4096 times to implement RESET SYSTEM EEPROM. Different firmware versions have the same code at different addresses.

A subtle detail of expanded addressing mode is important here: the final 16k page of program memory always maps to absolute address C000-FFFF. Even though this subroutine starts at EPROM location FC60F, it can always be accessed from C60F no matter what the program page register contains. This should mean that the final 16k of every firmware version contains the chip initialization code, interrupt vectors, and utility routines like this one.

 

[dan_n]

This disassembly listing shows the initialization code with the setup values for all control registers, i/o ports and peripherals. This is key to any deeper analysis of the firmware. As mentioned above, the listing shows the code starting at address C000 while the actual EPROM location is FC000. It sets up the following memory map:

22-bit Expansion Address	Internal 16-bit Address
	0000 01FF	CPU registers
	0200 02FF	CS0 - DSP
	0300 037F	CS1 - ?
	0380 03FF	CS2 - peripherals: serial J2-J5, ethernet, etc.
3C0000 3FFFFF	0400 07FF	CS3+EPAGE - external EEPROM
	0800 0BFF	CPU SRAM
	1000 1FFF	CPU EEPROM
	2000 6FFF	non-paged external SRAM
300000 3FFFFF	7000 7FFF	CSD+DPAGE - external SRAM
000000 (CSP1) 1FFFFF 200000 (CSP0) 3FFFFF	8000 BFFF	CSP1+PPAGE language EPROM CSP0+PPAGE firmware EPROM
3FC000 3FFFFF	C000 FFFF	non-paged CSP0 EPROM

 

[ibjeepin]

It's amazing work, and I would like to contribute if I can. Again, what is your goal with all of this reverse engineering? Build a modern board? Just document stuff for repair?

I am impressed with all the reverse engineering efforts here. Thanks the information provided is priceless considering Leviton did not release all of it after discarding the line.