Hi everyone,
I’m trying to troubleshoot a
Hikvision DS-7616NI-Q2/16P that is about 4 years old. I originally installed it for a client, and it was running with a UPS, but the client later removed the UPS. I suspect the intermittent power cuts and power cycling may have caused the problem.
It first started complaining about an
RTC/CMOS battery problem. I replaced the battery, but the RTC issue continued.
Now the bigger problem is that
the NVR will not retain any configuration. I can activate it, configure everything, save the settings, and it works normally. But as soon as I restart it,
all settings are gone and it comes back to the initial activation screen as if it were a brand-new NVR.
I have already tried:
- Replacing the RTC/CMOS battery
- Factory resetting it
- Removing all HDDs and testing without them
- Reconfiguring it from scratch
- Trying to upgrade the firmware
- Trying to re-flash the same firmware
The firmware upgrade gives
"Failed to get the upgrade status."
The current firmware is
V4.75.207 build 240604.
I came across some discussions mentioning possible
NVRAM/flash storage failure or internal configuration storage failure.
Has anyone experienced this with this model, and is there a way to repair/reprogram the configuration storage, or is this likely a mainboard replacement situation?
Any advice or experience with this particular failure would be greatly appreciated.
UPDATE / RESOLVED: Hikvision DS-7616NI-Q2/16P(C) Repeatedly Returning to Activation Screen After Reboot
Hi everyone,
I'm happy to report that I have finally managed to get this Hikvision NVR working again after an extended troubleshooting process. I wanted to document what I did, thank the two members who offered advice in this thread, and share the outcome for anyone who might encounter a similar problem.
DEVICE DETAILS
- Model: Hikvision DS-7616NI-Q2/16P
- Hardware variant: (C)
- Firmware: V4.75.207, build 240604
- Approximate age: Four years
- Installation: Client's premises
1. THE ORIGINAL PROBLEM
The NVR started exhibiting an RTC/CMOS battery warning. There was also a history of possible intermittent power interruptions after the UPS had been removed from the installation.
I replaced the CMOS battery with a new 3.0 V battery, but the main problem persisted. Whenever I restarted the NVR, it returned to the activation screen as though it had lost its configuration.
Other symptoms included the recorder reverting to its previous IP address, 192.168.1.8, despite my DHCP configuration. SADP also reported the device as inactive.
Although I could configure the NVR and use it normally for a while, the problem returned after restarting it. This made me suspect that the recorder was not retaining its configuration properly.
2. FIRMWARE TROUBLESHOOTING
My initial attempts to reflash the existing firmware through the NVR's web browser were unsuccessful.
I eventually discovered that I could successfully reflash the same firmware, V4.75.207, build 240604, using a USB thumb drive directly on the NVR itself. The local USB upgrade procedure worked where the browser-based method had failed.
After replacing the CMOS battery and successfully reflashing the existing firmware through USB, the date and time began surviving restarts. However, the activation-screen problem remained.
The NVR continued behaving as though its configuration was not being retained. I therefore shifted my investigation towards the hardware responsible for non-volatile data storage.
3. INVESTIGATING THE MEMORY COMPONENTS
I opened the NVR and examined the board, paying particular attention to the memory components that might be involved in configuration retention.
During the investigation, I inspected an eight-pin component marked NSi81 / 00N / X037B7. I also examined the MXIC-marked memory component closer to the processor.
The component I eventually reheated was identified as the Macronix MX35LF1G24AD-Z4I, a non-volatile SLC NAND Flash memory device manufactured by Macronix International.
Given the persistent configuration-retention symptoms, I suspected that a hardware-related issue involving this component or its surrounding connections might be responsible.
I could not establish the precise hardware failure through component-level measurements, but I decided to investigate this area further.
4. REHEATING THE MACRONIX NAND FLASH
After the previous troubleshooting attempts, I reheated the Macronix MX35LF1G24AD-Z4I SLC NAND Flash component and allowed it to cool before reconnecting the NVR for testing.
I connected the recorder to a TV, went through the usual activation process, and configured a new password.
I then restarted the NVR.
To my surprise, it rebooted normally instead of returning to the activation screen.
I subsequently accessed the recorder through its web browser and exported the system log.
This was the first clear indication that the NVR's behaviour had changed following the intervention.
5. FOLLOW-UP TESTING
Rather than immediately declaring the repair successful, I continued testing the recorder.
In my latest test, I powered off the NVR without performing a proper shutdown. After powering it back on, the recorder started normally and accepted the new pattern.
This was particularly encouraging because the original fault repeatedly returned after restarts.
The recorder has now passed the restart and power-interruption tests I have performed since the intervention, without returning to the activation screen.
6. CURRENT STATUS AND FIRMWARE DECISION
The NVR is currently running its original V4.75.207, build 240604 firmware.
Since the recorder is now behaving normally, I have decided not to make any further firmware changes for the moment. I will continue monitoring its stability and retain a backup of its configuration.
I also intend to contact Hikvision support to ask whether a newer firmware compatible specifically with hardware variant (C) is available. I do not want to introduce another variable while the recorder is working again.
7. MY CONCLUSION
The successful recovery followed the reheating and cooling of the Macronix MX35LF1G24AD-Z4I NAND Flash component, after replacing the CMOS battery and successfully reflashing the existing firmware through the local USB interface.
However, I cannot conclusively say whether the improvement resulted from a temperature-sensitive solder connection, an intermittent memory-related fault, or another hardware condition affected by the heating process. I did not perform the measurements needed to identify the precise failure mechanism.
The sequence of events strongly suggests that the problem may have involved the hardware or connections associated with configuration retention, but further testing would be necessary to confirm the root cause.
I would not recommend reheating a NAND Flash component as a routine repair without proper diagnosis and suitable equipment, because uncontrolled heating can damage the component or circuit board.
8. THANK YOU TO THE IPCAMTALK COMMUNITY
Finally, I want to sincerely thank the two members who took the time to offer advice in my original thread.
Your contributions encouraged me to continue investigating the problem instead of giving up on the recorder. I appreciate the time and technical knowledge you shared.
I'm posting this update to report the successful recovery, document the troubleshooting process, and close the loop on my original question.
Hopefully, the information will be useful to another technician who encounters similar symptoms with a Hikvision NVR.
Thanks again, everyone. I really appreciate the help!
