The good news are that my cams came back to life!
The first one was not recognized anymore by the NVR but by connecting my PC directly on the NVR (and changing IP config to belong to the same subnet), I reached the camera then reinstalled the firmware (took the excellent kit provided by
@cor35vet :
Dahua Firmware Mod Kit + Modded Dahua Firmware)
For the second cam, it was more complex, I was unable to login anymore, and the cam was not detected by Dahua ConfigTool; the cam looked like bricked.
I followed instructions of this thread:
Dahua IPC unbricking / recovery over serial UART and TFTP, again thanks to
@cor35vet given in the above link:
1 - I bought a USB 2.0 to TTL UART Module Serial Converter CP2102 STC:
https://www.ebay.fr/itm/Replace-FT232-6Pin-USB-2-0-to-TTL-UART-Module-Serial-Converter-CP2102-STC/321546809495?ssPageName=STRK:MEBIDX:IT&_trksid=p2060353.m2749.l2649
2 - The module went few weeks later but without any driver. I found this one, running well on my Windows 7 PC:
USB to UART Bridge VCP Drivers | Silicon Labs
3 - Downloaded PuTTY terminal application here:
Download PuTTY: latest release (0.70)
4 - Downloaded TFTPd (FTP server allowing your cam to upload the firmware stored on your PC):
TFTP server
5 - And finally downloaded the firmware from
@cor35vet (see above). There is a new one on dahua but in chinese, I chosen to not play with it
!
6 - Connected my PC to the NVR and configured IP to be in the same subnet of the NVR (10.0.0.X in my case)
7 - Configured PuTTY:
- Session category:
- Serial line: COM4
- Speed: 115200
- Connection type: Serial
- Connection->Serial category:
- Speed (baud): 115200
- Data bits: 8
- Stop bits: 1
- Parity: None
- Flow control: None
8 - Configured tftpd64, simply by selecting the directory where I unzipped the firmware
9 - Unmounted the cam and the electronic board to access the 4 pins just under the screw (top right on this photo provided by
@keithshlo )
From left to right: RX, TX, GND, VCC
Then connected (as I can because no connector!):
- TX from the CP2102 module to RX on the cam
- RX from the CP2102 module to TX on the cam
- GND to GND
10 - Then connected the CP2102 module to the PC and power up the cam
11 - I saw this text running on PuTTY:
Code:
U-Boot 2010.06-svn3054 (Mar 13 2016 - 05:41:48)
DRAM: 1 GiB
gBootLogPtr:80b80008.
Check spi flash controller v350... Found
Spi(cs1) ID: 0xC8 0x40 0x18 0xC8 0x40 0x18
Spi(cs1): Block:64KB Chip:16MB Name:"GD25Q128"
partition file version 2
rootfstype squashfs root /dev/mtdblock7
In: serial
Out: serial
Err: serial
TEXT_BASE:81000000
Net: PHY found at 3
ETH0: PHY(phyaddr=-1, rmii) not link!
Try again use backup_serverip
ETH0: PHY(phyaddr=-1, rmii) not link!
Failed to get info.txt
Fail to get info file!
Init error!
ETH0: PHY(phyaddr=-1, rmii) not link!
## Booting kernel from Legacy Image at 82000000 ...
Image Name: Linux-3.4.35
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1438272 Bytes = 1.4 MiB
Load Address: 80008000
Entry Point: 80008000
Loading Kernel Image ...OK
OK
partition file version 2
rootfstype squashfs root /dev/mtdblock7
fail to load bootargsParameters.txt
fail to load bootargsParameters.txt file
get bootargs info failed
cmdLine mem=87M console=ttyS0,115200 root=/dev/mtdblock7 rootfstype=squashfs
crashflasg:1, logmagic:54410011.
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Good news, the cam was not totally dead!
12 - Did the same (restarted a session, powered the cam) but this time pushing the '*' key on my keyboard. Magically, the boot sequence stopped and I was able to enter commands
13 - Used setenv to configure the ethernet & server address:
- setenv ipaddr 10.0.0.X
- setenv gatewayip 10.0.0.1
- setenv netmask 255.255.255.0
- setenv serverip 10.0.0.Y (IP of my PC running tftpd)
14 - Ping my PC: ping $serverip (and seen a message saying that the server is alive)
15 - Ran the commands:
run dr
run dk
run du
run dw
run dp
run dc
boot
16 - The cam booted and I heard noise from the focus (Infrared went on then off also).
17 - After few seconds I launched ConfigTool and the cam was detected again. Miracle!
In both cases, I can't explain why the cams suddenly turned into this kind of zombie state!
