No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


On the OptiX OSN 3500, the Standby GXCS Receives Frequent Cold Resets Due to an FPGA Problem

Publication Date:  2019-07-16 Views:  118 Downloads:  0

Issue Description

On the OptiX OSN 3500 of version, the standby GXCS receives frequent cold resets at an interval of five minutes. In addition, the board reports the HSC_UNAVAIL, BD_STATUS, and TR_LOC alarms. The board runs N1GXCSA version 2.14 and FPGA 310. 


Alarm Information



Handling Process

1. Query the reset records of the board. The following cold resets are found:
2007-09-15 [16:50:20] 0xffffffff XcsConfigModule 1970
2007-09-15 [16:50:21] 0xf0000011 reset:tMMXcsSyn 1229
2. Based on the preceding cause analysis, the problem is due to the defect in FPGA 310 on the N1GXCSA. Upgrade the NE software to V100R002C02B025SP02 (version or later that works with FPGA 330. 


Root Cause

1. FPGA 310 on the N1GXCSA has a design defect. When the standby GXCS attempts to keep pace with the active GXCS, the 8 kbit/s signal that the standby GXCS offers each function chip may lose the frame header temporarily. If services are being configured during the loss of the frame header, chip SD572 runs into a short page switching failure during the service configurations. When finding that the page is not switched within the specified time, the task for detecting the completion of page switching performs a cold reset on the standby GXCS.
2. When the standby GXCS restarts after the cold reset, the NE redelivers service configurations to the standby GXCS. The standby GXCS, however, is more likely to offer an 8 kbit/s signal without a frame header. This is because the standby GXCS requires certain time to keep pace with the active GXCS. As a result, chip SD572 is more likely to fail to switch the page, and consequently, the standby GXCS is more likely to receive a cold reset. Repeatedly, the standby GXCS receives frequent cold resets.
3. The standby GXCS meets with the loss of frame header only when the standby GXCS attempts to keep pace with the active GXCS. The active GXCS keeps tracing its own clock and is free from the out-of-synchronization problem. Therefore, the active GXCS never receives such a cold reset. 


The N1GXCSA can be considered to have such a defect if the following two conditions are true:
The standby N1GXCSA receives frequent cold resets and records the cold resets as above.
The standby N1GXCSA runs FPGA 310.
The problem also exists in the EXCSA that runs chip SD572 and FPGA 310.