MK5 Intermittent C Processor LCC alarm message "Fail Rom - Main 3"

We are currently doing a MK5 panel upgrade were we are replacing all cards , cables and prom chips. After successfully completing this job and powering up we were going well with A7 status on all processors.
We returned the following morning to find the status on C processor LCC display as "Fail Rom - Main 3"
We have been following a process of elimination putting the old and new chips back in various combinations to see if we can narrow down to the problem. So far we have primarily focused on chips U11,U12, U22 and U23 on the SDCC card. Our latest check is with all the new chips re-installed on a different SDCC card. But as we have no idea how long it is to this failure mode occurs we are really best guessing. A real help would be it if someone could tell us were more accurately to focus our investigation and which chips or cards the Status failure refers to. With the "Fail Rom- Main 3" on display the keypad cannot be accessed to try and get more information. So hopefully someone can tell us to directly look at 1. LCC and chips U6, U7 2. SDCC and chips U11, U12 ,U22 and U23 or 3. TCCA card and chips U8, U9

Thanks
Topcat
 

Attachments

What kind of upgrade do you perform?

It might be that something went wrong during upgrade ...

Did you perform a "troubleshooting issue to get A7 STATUS " as per GE manual ...

Any PROM have been changed ?
 
I suggest to do followings things:


ALARM.LST: Compiled list of alarms.
It contains the Drop Number, Signal Name and Description for every Process Alarm. For information purposes only. This file should be generated every time there is a change made to ALARM.DAT and/or ALLOCSSP.ASG: Generated by ALARM_L.EXE. Command:

F:\UNITn>ALARM_L
or
F:\UNITn>MK5MAKE

As we dont see a drop number for this "error message "
 
It's pretty likely that the "new" cards being installed are actually cards which have been around for years, or even decades. There is really only one company that can fully test Mark* V cards and every other company which sells Mark* V cards (and some of them advertise them as "tested") are just (sometimes--not in every case) powering-up cards in a panel just to see if they will get to A6 or A7 (A6 is the state where the card is communicating and is capable of writing to its outputs, but it hasn't received "full cofirmation" that it is safe to do so.)

Also, even if you bought cards from a company and that company could GUARANTEE that card were purchased or came from a warehouse/stores location and the cards were "new" and never used, they CAN'T guarantee that. MANY technicians (site personnel as well as OEM personnel) exchange cards with ones from warehouse/stores, and if the card didn't solve the problem they DON'T remove the card from the warehouse/stores and re-install the card which was removed during the troubleshooting process. So, it's quite possible--and even very likely--that some cards sitting on a warehouse/stores on a shelf are cards which might even be years (or decades) old, just in a spares box.

If I recall correctly, ROM chips are soldered to Mark* V printed circuit cards and can't be replaced. The chips the OP (Original Poster) is listing are EPROM chips which are socketed chips that contain algorithms and I/O processing information (NOT I/O or Control Constants--those are downloaded to and stored on the U9 socketed chip on the DCC/SDCC card). (EPROM chips differ from EEPROM chips in that they can be erased using UV light, whereas EEPROM chips can be erased electronically.) And, the OP is writing about an alarm related to ROM chip(s), not EPROM chips (or RAM chips--there are several kinds of chips used on Mark* V cards, including DPM (Dual-Ported Memory) chips). In other words, it's very likely (if my memory is correct) that a failed ROM chip (or chips) isn't replaceable, and is NOT one of the socketed chips which are exchanged when replacing Mark* V cards.

I'm sorry to be the bearer of bad news--because unless someone is currently producing NEW, UNUSED Mark* V cards (NOT Mark* V-compatible Mark* VIe cards!! but Mark* V cards)--about the cards you are installing in the panel. If they ARE NOT newly-produced, unused cards then it's highly likey they are several years, or as much as two decades old. Even if they were unused spare cards from a warehouse/stores, they are still many years (decades) old and unless they were maintained in an environmentally-controlled environment (specifically temperature and humidity), they are still years old. Even if they were tested by the one company that can properly test all functionality of Mark* V cards, they are still years (decades) old.

The problem is most likely the card--not any replaceable, socketed chip. EPROMs, properly handled are very robust chips. the U9 EEPROM chips used on Mark* V cards DOES have a finite number of writes/re-writes it can endure--but most sites will never reach that limit, which was in the thousands of writes/re-writes (I only ever saw them fail in factory settings where they were downloaded to and over-written tens of times a days for months/years). The most likely culprit is the DCC/SDCC card, followed by the LCC/SLCC card, and possibly the TCCA card. I have seen one occasion and heard of another occasion where the very unusual problem with a <C> processor was resolved by replacing the CTBA card--which does have some non-replaceable active components on it (no other terminal board in the Mark* V has any active components on it--only passive components).

Sorry; wish the news was better. Please write back to let us know what you find.

It would also be VERY HELPFUL if you can tell us the condition the cards were sold as. You don't have to mention the seller, just the condition they said the cards were in when they were offering them for sale.

Best of luck, and thank you in advance for telling us the condition the cards were sold as.
 
A new set of prom chips were installed on the [C] core cards and the processor has remained at A7 healthy status for over 3 days so we are confident this issue is now resolved. Although we did not 100% bottom out the root cause we believe that the issue was with the U6 or U7 chips on the LCC board.
Thanks to those who provided us with feedback
regards
Topcat
 
Top