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 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.

 

[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.