DMP XR500 Outputs Stuck Following CMOS Battery Failure

Hey everyone,

I have a DMP XR-500 running on my demonstration board that experienced a CMOS battery failure while I was away at college. I was able to recover the system programming, and everything is back to normal operation except for three open collector outputs (#3-5) driving an 861 relay card for the panel which are stuck in the active state. The fourth open collector output, #6, is operating properly.

There are no alarms or troubles in the system, so I know that the outputs are not operating for a legitimate cause. I have removed them from all locations where they are specified to activate in the programming and disabled the output group, yet they continue to activate.

I am able to manually deactivate the outputs from the system menu, so I know this is not a hardware issue, but they immediately reactivate once the menu is closed.

Any ideas on this issue?

I’m not a DMP guy but it sounds like even though you were able to retrieve the program, it may have been corrupted.

I figured that the output configurations may have been bad, even though looking through the programmer settings they seemed correct, so I completely initialized (cleared) all of the current output settings from the panel and re-programmed them. This still did nothing to solve the issue.

I have not the slightest clue about DMP, but I may have some helpful general advice. Have you tried a power-cycle? What about performing actions that would trigger the outputs to activate and disarming/resetting those actions? As a person with some experience in computer programming, the configuration may save variables that aren’t able to be changed by the user, but are saved and read anyway. Like it was previously suggested, the configuration may be corrupted. Where the corruption may be, we don’t know, but I wouldn’t doubt that the configuration data has multiple variables for outputs. For example, let’s say there’s a “default state” variable that is set when the configuration is entered, depending on the output programming. Well, let’s say that before the problem started, they were all set to “open”. If these variables were corrupted and are now set to “closed”, then the configuration would still appear correct to the user (and technically it would be), but because these default states were set when the configuration was originally set, they aren’t touched unless the configuration changes. When you set the output configuration, did you default it, exit out, then set it back again? I’m not sure that it may do anything if you didn’t exit out. If all else fails, factory reset.

I power cycled the system several times while working towards restoring it, in addition to several manual CPU resets from the onboard jumper.

Initializing the output settings should have wiped all of the configuration and variables associated with the outputs. I am able to manually cycle the output conditions, and was hopeful that may “knock” some things into place, but to no avail.

At the component level, it looks like the active device data and zone/output states are stored in a dynamic RAM chip-set, while the programming information itself is in a non-volatile Flash or EEPROM chip, so it was not entirely lost. Running the programmer and re-saving the program was enough to return the system to normal operations with the new battery. When I initialized the output group, it was essentially defaulted and then reentered within the programming session.

I was able to find a solution for this after all.

It appears that the 3V CMOS battery actually provides pull-up power to these outputs to hold the tri-state buffer in the high impedance state. I was finally able to get a new CR2325 battery for the unit, and all of the outputs returned to normal operation with the new battery in place.