HAI Omni engineer/developer thread

[dan_n]

There's some valuable HAI hardware/software knowledge posted on this forum by highly skilled engineers/developers. But it's scattered all over and mixed into threads that are mainly end user questions.

It would be very useful to have all of this information in one thread where developers can do deep dives into details that would bore most users, and not have pages filled up with user help requests. The end result should be hardware/software/instructions that benefit everyone.

For example: I can now retrieve the installer code from any OmniPro II (details in post #2), and confirm replacing the network chip restores network connectivity (details in post #3)

 

[dan_n]

MC68HC812A4/MC812A4CPVE8 cpu has 4kB internal EEPROM. This is where all the codes are stored, and the configuration bytes that tell the firmware what type of board it's running on (Pro II, 2e, LTe). The cpu runs in Normal Expanded Narrow mode and all memory remapping (registers, ram, EEPROM) is at default reset values.

Used a BDM interface (JPM connector pads to right of cpu appear to be standard BDM) to dump EEPROM memory of a running board.
dump from OmniPro II 20A01-31 (flash firmware 4.0b, made 2016?), confirmed code locations the same on OmniPro II 20A01-21 (EPROM chip firmware 4.0b, made 2005):

EEPROM starts at 1000 (F000 in Single mode)
117F-1180	Code 01 (Master)	04 D2 (1234)
118D-118E	Code 02	10 E1 (4321)
...	Code nn
1BB3-1BB4	Installer code	04 57 (1111)
1BB6-1BB7	PC Access code	04 57 (1111)
1FE8-1FEF	Network Encryption Key-1
1FF0-1FF7	Network Encryption Key-2
1FF9-1FFE	Ethernet MAC address

Each Master/Manager/User code record is 14 bytes containing the code value (16-bit integer), type of code (1 byte), time it's valid, etc. Installer and PC Access code are just 16-bit integers.

It's very possible that older firmware puts these at different locations.

What prompted me to dig into this is the cpu datasheet specs internal EEPROM data retention at 10 years (max temp). It's possible that 20 year old panels have weak EEPROM cells that will start giving random values. I want to find a way to rewrite the entire EEPROM to gain another 10-20 years.

It's not quite there. I get inconsistent memory dumps that may be related to using a pogo pin adapter instead of soldering wires to the board. It needs to be much more stable before I attempt writing the EEPROM. EDIT: inconsistent memory dumps solved, details in post #8 including the 1k resistor needed for the cpu to reset into Special Single mode

 

[dan_n]

Replacing the RTL8019AS ethernet chip does restore network connectivity. I had a OmniPro II with a completely dead network port (no LEDs, no activity detected by any of my Windows/Linux network tools). After replacing the chip, the board was on the network and PC Access could connect and download, etc.

I'm not sure if this chip is still in production but it isn't available from reputable suppliers. Some new chips were known to have a high early failure rate as shown here. I ordered 5 chips on Ebay from China expecting all 5 to look like the good ones shown in the link. 2 had the round dimple (good), 3 had the bar (not good in that link, but the datasheet shows the bar). The 2 "good" chips didn't have the same surface texture. I installed the one good chip with a surface texture that matched the original.

Removal/install requires advanced equipment and skills. Boards from the late 90s-early 2000s have thin copper traces/pads that are easily damaged. The chip is right up against 2 things that would be damaged by hot air: the pulse transformer and the 20MHz crystal. There is no room for any kind of heat shield so both must be removed first. I used a Hakko FR-301 to remove the pulse transformer; a cheap solder sucker may work or be too slow and wreck the pads. Replace the chip using standard hot air methods and some extra care not to damage the pads (not too much heat for too long). I used a stereo microscope during soldering and for inspection. Push each pin with a needle probe to verify a solid connection and use high magnification to find solder bridges. I had one tiny whisker solder bridge that I almost missed even at highest magnification.

More info and photo about unused pads in post #11

 

[dan_n]

ConsoleBus protocol decode:

Communication is RS-485 using standard serial format: 9600 baud, 1 start, 8 data lsb first, 1 stop, no parity

Current understanding is that many devices (consoles, wireless receiver, etc.) can be attached to the bus, but none of them can transmit until they are polled by the panel.

Every 30mS the panel sends a 3-byte polling message (02 31 03), console-1 responds with a 1 byte (03) "empty" message, then the panel sends another 3-byte (02 ** 03) message where ** changes (increments) each time: ** values range from 31-40 for console addresses 1-16. At startup the panel tries to find devices by polling all 16 console addresses consecutively (1 every 30mS) before repeating the whole cycle again several times.

When a console key is pressed, the console won't transmit anything until the next polling from the panel. Example, press the '#' key: panel sends 3-byte polling message (02 31 03), console-1 sends 2-bytes (23 03) the 1st is the key pressed.

Panel Message	Console-1 Response
02 31 03 (polling every 30mS)	03 (empty response)
02 31 03	23 03 (if '#' key was pressed)
02 31 06 03	03 (status?)
02 31 12 30 30 14 22 03	06 03 (status?)
02 31 20 20 12 30 30 14 22 03	06 03 (status?)

The longest panel message I saw was 73 bytes for "* SET UP TIME * / PHONE LINE DEAD TRBL NOW". (screenshot attached)

Expansion enclosure addresses may start at 41. I setup for 4 expansion enclosures (but none connected) and the panel sends the following polling message every 2 seconds (always the same, 41 doesn't change):

02 41 53 30 31 30 30 30 30 30 30 30 30 30 31 03

poll/discovery for expansion enclosure?

The key to this analysis was to attach a logic analyzer to the digital (cpu) side of the RS-485 transceiver chip (SP483) to clearly see when data was being received or transmitted. The attached screenshots were captured inside a console so RX is data from the panel, TX is data going to the panel.

 

[dwalt]

MC68HC812A4 cpu has 4kB internal EEPROM. This is where all the codes are stored, and the configuration bytes that tell the firmware what type of board it's running on (Pro II, 2e, LTe). The cpu runs in Normal expanded narrow mode and all memory remapping (registers, ram, EEPROM) is at default reset values.

Used a BDM interface to dump EEPROM memory of a running board.
dump from OmniPro II 20A01-31 (flash firmware 4.0b, made 2016?), confirmed the same on OmniPro II 20A01-21 (EPROM chip firmware 4.0b, made 2005):

EEPROM starts at 1000:
117F-1180  Code 01      04 D2 (1234)
118D-118E  Code 02      10 E1 (4321)
...      Code nn
1BB3-1BB4  Installer    04 57 (1111)
1BB6-1BB7  PC Access    04 57 (1111)

Each Master/Manager/User code record is 14 bytes containing the code value (16-bit integer), type of code (1 byte), time it's valid, etc. Installer and PC Access code are just 16-bit integers.

It's very possible that older firmware puts these at different locations.

What prompted me to dig into this is the cpu datasheet specs internal EEPROM data retention at 10 years (max temp). It's possible that 20 year old panels have weak EEPROM cells that will start giving random values. I want to find a way to rewrite the entire EEPROM to gain another 10-20 years.

It's not quite there. I get inconsistent memory dumps that may be related to using a pogo pin adapter instead of soldering wires to the board. It needs to be much more stable before I attempt writing the EEPROM.

This is very encouraging. Is there any way to dump the eeprom contents from the CPU offline? What hardware are you using to do this?
Thx

 

[dan_n]

This is very encouraging. Is there any way to dump the eeprom contents from the CPU offline? What hardware are you using to do this?
Thx

I'm not sure how you mean offline: cpu held in reset or cpu removed from board? Powering the cpu on the board powers everything else on the 5V rail.

In theory a BDM interface could power the target cpu but mine can't. I don't think it matters since it's a hardware background interface separate from the cpu core and shouldn't affect the running cpu except for an extra latency cycle here or there. I guess it does matter for writing, the cpu would have to be held in reset.

I use USBDM hardware(JS16) that I built myself so I know it has the proper io voltage levels. The cheap ones on Ebay/AliEx may or may not work.

 

[dwalt]

I'm not sure how you mean offline: cpu held in reset or cpu removed from board? Powering the cpu on the board powers everything else on the 5V rail.

In theory a BDM interface could power the target cpu but mine can't. I don't think it matters since it's a hardware background interface separate from the cpu core and shouldn't affect the running cpu except for an extra latency cycle here or there. I guess it does matter for writing, the cpu would have to be held in reset.

I use USBDM hardware(JS16) that I built myself so I know it has the proper io voltage levels. The cheap ones on Ebay/AliEx may or may not work.

Sorry I wasn't clear. I meant cpu removed from board. It doesn't matter as I have no experience removing smd chips anyway.
Please keep us updated on your progress.

 

[dan_n]

Tracking down the inconsistent cpu internal EEPROM dumps turned into a lot more work than expected. The main issue is this cpu is very old and not directly supported by modern debugger hw/sw, and getting it into full debug mode works differently than cpus even 1-2 generation newer.

It should support reading EEPROM while the cpu is running normally, but it would always give a repeating pattern of bytes in different places each time. For our purposes halting the cpu and then reading EEPROM is acceptable but required some extra work.

The debugger can put the chip in full active debug mode (halted) by resetting it in a special way. The problem is this old cpu only supports that in one operating mode: Special Single. The Omni boards are configured to select Expanded Narrow mode at reset. I had to trace out the circuit and find a pad that when grounded through a 1k resistor lets the debugger put the cpu into Special Single mode at reset with full active debug mode. Once I did that I got 100% consistent internal EEPROM dumps (EEPROM start address is F000 in this mode).

Writing the EEPROM will require some future work since the current debugger sw doesn't directly support this cpu.

To allow the debugger to force the cpu into Special Single mode, temporarily clip a 1k resistor as shown in the attached pic (the board cannot run with this resistor permanently connected). The cpu MODA, MODB pins determine the startup mode after reset but the Omni boards reuse these pins to drive the PHONE and STATUS leds. So you can't just short MODA to ground or it will burn out the PHONE led. When the resistor is making contact the PHONE led will get slightly brighter, assuming no phone is connected. I power up the board normally, clip the resistor on, then have the BDM reset the cpu and dump internal EEPROM.



EDIT: I had trouble getting an older (Rev-C8) Pro II to reliably reset into Special Single mode using the resistor location above. The board has another 1k resistor between that pad the the cpu pin, and the voltage at the pin just wasn't getting low enough.

I now hold the pulldown resistor on a pad that goes directly to the MODA pin on the cpu as shown in this pic:

 

[dwalt]

This is very interesting. For my use, its much more important to read the eeprom than write it. Reading out the installer code could make use of many of the boards for sale with unknown installer codes.

 

[dan_n]

I have confirmed that replacing the RTL8019AS ethernet chip does restore network connectivity, details in post #3

 

[dan_n]

I just realized that if some pads are damaged while removing the ethernet chip it may not be a big deal. The attached photo from my microscope shows that most of the pads on the top and right side aren't connected to anything at all and most pads on the left side are connected to ground. An unconnected pin could be ignored while a ground pin could just be shorted to the grounded pin next to it.

 

[dan_n]

I added a rough outline of the consolebus protocol to post #4

My original motivation was to make a console emulator to automate some of the bench testing I was doing. But I no longer have a need for that so I may not add much more. If someone else wants to contribute I can add info and links to post #4

 

[bluelake321]

Here is as far as I got reversing the RS485 condole protocol - I have not had time to get back to it.​

​

Protocol Overview​

• Messages use ASCII Encoding
  • Each chunk of info starts with 0x02 (STX)
  • Each chunk of data ends with 0x03 (ETX)
  • Use Device Control (DC1 – DC4) characters for unknown purposes
• Uses a 16 number sequence counter
• Use a master (controller) / slave (console) arrangement (polling)
• The console only acknowledges polling requests or replies with button press data.
• Message layout
  • Sequence Counter
  • Destination Address
  • Various Data

When no console is connected, the controller sends out 16 messages (0x31-0x40). Each address relates to the console’s address (set at the console in the menu).

• 0x02 0x31 0x03…0x02 0x40 0x03

The controller initiates communication with a console after “hearing” the console respond to its “address”. Response is almost always 0x03.

Console “setup”​

1. The controller sends a polling command with the console address (Console 1 = 0x31)
2. The console acknowledges the poll by replying with 0x03??
3. The controller sends a console initiation message.

Normal Polling​

1. The controller sends a polling message to a specific address (GREEN)
2. The console responds with an acknowledgement -or- a button press message (BLUE)

0 = 0x30	4 = 0x43	8 = 0x38	AWAY = 0x48	VACA = ???
1 = 0x31	5 = 0x35	9 = 0x39	NIGHT = 0x49	UP = 0x4D
2 = 0x32	6 = 0x36	* = 0x2A	DAY = 0x4A	DOWN = 0x4F
3 = 0x33	7 = 0x37	# = 0x23	OFF = 0x4B	PARTY = ???

Sending Text to a Console​

Text is sent to consoles in ASCII form. Info sent in two message chunks – limit on characters sent in one transmission (70-71 Char)??

1. Starts with a sequence number
2. Then the console address
3. 0x11, 0x21, 0x20 (DCI ! _) sent to indicate start of bottom line of text. (Line Number????)
4. ASCII characters for bottom line
5. 0x11,0x20, 0x20 (DC1 _ _) sent to indicate start of top line of text
6. ASCII characters for top line
7. 0x12, 0x00, 0x00, 0x14 0x22 0x03 (DC2 0 0 DC4 “ ETX) to indicate end of text.

Once the text has been sent, the console acknowledges the receipt with an actual ASCII ACK message.

 

[bluelake321]

 

[bluelake321]

OmniPro PCB Jumpers

Jumper	Populated?	Name	Configuration
JP1	YES	Serial 1 Standard	RS232 (Left) / RS485 (Right)
JP2	YES	Serial 2 Standard	RS232 (Left) / RS485 (Right)
JP3	YES	Serial 3 Standard	RS232 (Left) / RS485 (Right)
JP4	YES	Serial 4 Standard	RS232 (Left) / RS485 (Right)
JP5	YES	Serial 5 Standard	RS232 (Left) / RS485 (Right)
JP6	NO	UNKNOWN	2pin
JP7	NO	UNKNOWN	3pin
JP8	NO	UNKNOWN	3pin
JP9	NO	UNKNOWN	3pin
JP10	YES*	Progam Memory Location	Language EEPROM (Left) / Code EEPROM (Right)
JP11	YES	Zone 1 Input Type	Nomal (Left) / Smoke (Right)
JP12	YES	Zone 2 Input Type	Nomal (Left) / Smoke (Right)
JP13	YES	Zone 3 Input Type	Nomal (Left) / Smoke (Right)
JP14	YES	Zone 4 Input Type	Nomal (Left) / Smoke (Right)
JP15	YES*	Language Memory Location	Code EEPROM (Short)