Attempted Region change on DS-2CD3332 gone south. Is it fixable?

[venturis]

Hi Guys,

Need some advice on whether it may be possible to recover my Chinese region 2CD3332-i cam which become unresponsive after an attempt to apply the Brick Fix.

I broke the cardinal rule when curiosity got the better of me when I decided to try converting my chinese region 3MP 2CD3332 cams to Western Region. They have been working perfectly on firmware 5.1.6 for several years using a firmware that made them full english compatible however, they were not upgradeable without reverting back to chinese language.

After carefully reading the instructions contained in the post "DS-2CD2x32 BrickfixV2 brick recovery and full upgrade tool - enhanced." I decided to give it a try.

The first cam conversion went surprisingly well and the whole process was easier than expected. On that basis I decided to do the other five cams I own.

All was going well until I got to the last cam. Using the TFTP server to load the BrickFix tool completed successfully with the message "system update complete". However during the firmware loading process I noted that there was 2-3 ACK errors but they didn't seem to cause issues on the other cams that had shown the same.

After rebooting the cam for the first time, there was not response when attempting to Telnet. Furthermore, the cam could not be seen by the SADP tool. A few more sanity checks later I came to the conclusion the cam was borked.

This is what I've tried.

1. Attempted to reload the firmware using the TFTP server at startup. - no dice.
2. Tried to contact the cam using SADP tool
3. Changed the PC ip address to 192.168.1.128 and repeated steps 1 and 2 above.
4. Tried using a POE power supply instead of a 12VDC plugpack
5. Ping 192.0.0.64, No reply.
6. Ping 192.168.1.64, No reply

At this point I'm thinking the first firmware update to load the BrickFix tool somehow became corrupted. Most likely flash memory corruption since the previous 5 cams all worked ok using the same DAV file.

I now have the cam apart and noted that a small green LED on the rear of the main board lights up when powered on and seems to flash in unison with keystokes on my PC when trying to telnet to the device. This seems to confirm that it's not a power supply issue.

I have a USB to TTL cable but no JST connector to bring up the serial console. I have been on the hunt for a JST 4 pin connector but no luck so far. Will probably need to source one through Ebay from China.

My question is, with everything that I've tried, what is the likelihood that I will be able to recover this cam and if so, what are the steps to reload the DAV file from the serial console?

 

[alastairstevenson]

My question is, with everything that I've tried, what is the likelihood that I will be able to recover this cam

Pretty reasonable - though it will depend on the cause of the problem.
Hooking up to the serial console should show what's going on.

what are the steps to reload the DAV file from the serial console?

It will depend on what the problem is - causes can be many and varied.

no JST connector to bring up the serial console.

Search for 4-pin JST ZH 1.5mm wired connector.
Plenty of availability, usually sold in 10-packs, but as you say, can take a while shipping.

 

[venturis]

Because I couldn't wait another 4 weeks to take delivery of the JST connectors from China I decided to try my soldering skills and managed to successfully solder some fine wire to the RX and TX pads on PCB below the serial connector. For the ground I simply clamped a wire under one of the PCB mounting screws since it all seems to be commonly grounded.

I am now able to achieve a stable serial connection to the camera and had a play around. I tried a number of different things

1. Tried to Xmodem the digicap.dav file to the cam which failed every time with a CRC error at the conclusion of the transfer.
2. Tried TFTP the digicap.dav file to the cam using the TFTP command which appeared to complete successfully but on reboot nothing had changed.

Tried several different digicap.dav files just to be certain I was not dealing with a corrupt file.

Below is a series of captures of the data from the camera. Would appreciate if someone can point me to what is going on.

The console output during an uninterrupted boot as follows:

U-Boot 1.3.4-30623 (Dec 6 2012 - 11:05:48)

ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
|RCV UDP pack timeout|
Unknown command:null
nand booting ...
load kernel...
load ramdisk...
init started: BusyBox v1.19.3 (2016-05-23 16:23:55 CST)
starting pid 375, tty '': '/etc/init.d/rcS'
Starting udev: [ OK ]
UBI device number 1, total 192 LEBs (24772608 bytes, 23.6 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 Ki
waiting for /dev/ubi1_0.
pri_iUpgSuccCnt:0x1, sec_iUpgSuccCnt:0x1
UBI device number 3, total 32 LEBs (4128768 bytes, 3.9 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
waiting for /dev/ubi3_0.
Check dir /davinci ok! (0)
UBI device number 4, total 32 LEBs (4128768 bytes, 3.9 MiB), available 0 LEBs (0 bytes), LEB size 129024 bytes (126.0 KiB)
waiting for /dev/ubi4_0.
Check dir /config ok! (0)
diagnose_way = 15, repair_way = 1, interval = 30
route: ioctl 0x890c failed: No such process
mount: mounting none on /proc/bus/usb failed: No such file or directory
/dav
map_size = 0x300000
nr_item = 3
addr_offset = 0x0 filename = orccode.bin
addr_offset = 0x200000 filename = orcme.bin
addr_offset = 0x2a0000 filename = default_binary.bin
mmap returns 0x402a3000
loading ./orccode.bin...addr = 0x402a3000, size = 0x1a0a91
loading ./orcme.bin...addr = 0x404a3000, size = 0x3a4fc
loading ./default_binary.bin...addr = 0x40543000, size = 0x40000
===============================
u_code version = 2016/4/6 3.0
===============================
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system reboot


U-Boot 1.3.4-30623 (Dec 6 2012 - 11:05:48)

ARM Clock: 480MHz
DDR Clock: 336MHz
Hit Ctrl+u to stop autoboot: 0
begin to enter mini system



After that, interrupting the boot with Cntrl-U and issuing a "printenv"

HKVS # printenv
ipaddr=192.0.0.64
serverip=192.0.0.128
gatewayip=0.0.0.0
netmask=255.255.255.0
ethaddr=44:19:b7:11:ce:60
loadaddr=0xc2000000
bootfile=digicap.dav
bootcmd=null
bootargs=console=ttyS0 initrd=0xc0a00000,0x400000 rw root=/dev/ram dbg=0
bootdelay=2


Issuing the HELP command reveals the following commands are available

HKVS # help
The following commands are supported:
boot help bios diag
mtest dump erase go
exec ping r8 r16
r32 reset saveenv printenv
setenv show usbdl w8
w16 w32 tftpboot bootm
readoob killb crc nandread
nandwrite ups upm format
update upf upa upr
upk updateb ubi bapi

Attempting to load teh digicap.dav using Xmodem protocol appears to transfer successfully but is alway met with a CRC failure

HKVS # ups
download digicap.dav to 0xc2000000 at 115200 bps...
start sending using the XMODEM protocol...
press ^X to quit
CCCCCCCCCcmd_update_serial: partition kernel do not need to update!
file:E¦¦ chksum error!r
upgrade failed!


Tried issuing a TFTP command from the console using both the Hikvision TFTP app and the Jounin versions both of which appear to transfer the digicap.dav completely but nothing changes after a reboot

HKVS # tftp
MAC: 44:19:b7:11:ce:60
TFTP from server 192.0.0.128; our IP address is 192.0.0.64
Filename: 'digicap.dav'
Load address: 0xc2000000
tftp transfer block size is set to 512 bytes
################################################################################
################################################################################
################################################################################
################################################################################
################################################################################
################################################################################
################################################################################
################################################################################
################################################################################
######### got 18666615 bytes (18229 KB)
HKVS #


I'd appreciate any help on what to do next.

 

[alastairstevenson]

All was going well until I got to the last cam. Using the TFTP server to load the BrickFix tool completed successfully with the message "system update complete".

What version of firmware did you use?
Going straight to 5.4.41 can be troublesome. Going straight to 5.4.5 is generally OK.

Tried to Xmodem the digicap.dav file to the cam which failed every time with a CRC error at the conclusion of the transfer.

Ignore Xmodem. You have an ethernet connection.

Tried TFTP the digicap.dav file to the cam using the TFTP command which appeared to complete successfully but on reboot nothing had changed.

Yes, all that does is download the digicap.dav file, it doesn't perform the firmware update.
You'd need to use the 'update' command to do that.

Below is a series of captures of the data from the camera.

Best to use the CODE tags, for readability. Check out the dropdown to the right of the emoticon in the edit bar.

diagnose_way = 15, repair_way = 1, interval = 30
.
begin to enter mini system
This suggests the camera is still running the brickfixV2 min-system, or 5.4.40 firmware.

Suggestion :
With a 5.4.5 digicap.dav firmware file, use the bootloader command 'update' to install it.
If that does not work - use the brickfixV2 firmware with the update command, and re-run the process.

 

[venturis]

Thanks Alastair. After a few more hours of blindly poking around the cam I finally have it running but it is now stuck in Chinese language.

Firstly, I tried loading the firmware using the "tftpboot" command which loaded the digicap.dav successfully. It was not until later that i realised I needed to issue an "update" command to write to the flash.

Unfortuately however, issuing the update command did nothing. Simply a blank prompt. I tried several versions of firmware, both the Brickfix EN and CN and the original 5.1.6 firmware. Made no difference whatever I tried.

Issuing the "upf" command kept prompting me for an "mImage" file that I didn't have.

After reading a number of posts I found the discussion between yourself and another forum user where you provided a copy of the mImage donor file.

I dropped one of the files into the TFTP directory and renamed to "mImage" and tried the "upf" command again and this time I there was progress. The mImage was read in by the cam however, it failed to write to the Recovery Partition. It didnt stop there however because it then started loading the digicap.dav file that was in the same folder and proceeded to flash the file successfully.

HKVS # upf
MAC: 44:19:b7:11:ce:60
TFTP from server 192.0.0.128; our IP address is 192.0.0.64
Filename: 'mImage'
Load address: 0xc2000000
tftp transfer block size is set to 512 bytes
################################################################################
################################################################################
################################################################################
################################################################################
################################################################################
######### got 10485760 bytes (10240 KB)
erase failed. <block 56>
Try next block...
cmd_update_mini_system:write RCVY partition failed!
[ INFO][MIN]FORMAT: Formatting Flash
[ INFO][MIN]FORMAT: ................................
[ INFO][MIN]FORMAT: Format Flash [OK]
[ INFO][MIN]TFTP: TFTP from server 192.0.0.128
[ INFO][MIN]TFTP: Filename: 'digicap.dav'
[ INFO][MIN]TFTP: ################################################################################
[ INFO][MIN]TFTP: ################################################################################
[ INFO][MIN]TFTP: ################################################################################
[ INFO][MIN]TFTP: ################################################################################
[ INFO][MIN]TFTP: ################################################################################
[ INFO][MIN]TFTP: ################################################################################
[ INFO][MIN]TFTP: ################################################################################
[ INFO][MIN]TFTP: ################################################################################
[ INFO][MIN]TFTP: ################################################################################
[ INFO][MIN]TFTP: #########
[ INFO][MIN]TFTP: Download File [OK]
[ INFO][MIN]BURN: File size is 18666048 bytes (18228 KB)
[ INFO][MIN]BURN: Writing Flash
[ INFO][MIN]BURN: ................................................
[ INFO][MIN]BURN: Write Flash [OK]
***** UPDATE COMPLETE *****

On reboot the camera web interface was back but in Chinese.

I've since tried using the same process to load the Brickfix but the end result is always an unresponsive cam without a working mini system.

It appears from the output above that I'm not able to write to the min system partition.

Whilst I now have a working cam, it is all Chinese and even after applying a ver 5.1.6 firmware update that previously override the CN langauge flag and provided english menus.

Any idea what I might do from here to get the Brickfix working?

 

[venturis]

I loaded 5.4.5 firmware as suggested which completed successfully however, I was unable to access the web interface, instead getting a language mismatch error which I suppose was to be expected.

I then tried loading BrickFix again using the TFTP server which installed successfully however, on reboot, no Mini system or Telnet available.

The only way to get the camera operational was to roll back to version 5.1.6 using the mImage file with the "upf" command since issuing the "update" command simply results in a system hang. The installation of the recovery image always fails but it seems to permit the system firmware from loading.

So, I am back on Version 5.1.6 but stuck with Chinese language and seemingly unable to apply the Brickfix in spite of successfully doing so on 5 other identical 2CD3332-i cams.

 

[alastairstevenson]

Wow! You've been on quite the exploratory journey.

Unfortuately however, issuing the update command did nothing. Simply a blank prompt. I tried several versions of firmware, both the Brickfix EN and CN and the original 5.1.6 firmware. Made no difference whatever I tried.

It sounds like you are right that there is some problem with the recovery partition.

I loaded 5.4.5 firmware as suggested which completed successfully however, I was unable to access the web interface, instead getting a language mismatch error which I suppose was to be expected.

That presumably is due to the original mtd6ro being in place.

So, I am back on Version 5.1.6 but stuck with Chinese language

Well, from that position you should be able to to the manual mtd hack.
You just need to be able to get mtd6ro out, modify it, and get it back and apply it.
With that version of firmware you won't be blocked by psh, there will presumably be a normal root shell. Maybe with 12345 or hiklinux if a password is needed.

When the camera boots up and you get the Chinese menus, what can you do at the serial console?
Is there a usable shell?
If so, is there a tftp command?

 

[venturis]

Well, from that position you should be able to to the manual mtd hack.
You just need to be able to get mtd6ro out, modify it, and get it back and apply it.
With that version of firmware you won't be blocked by psh, there will presumably be a normal root shell. Maybe with 12345 or hiklinux if a password is needed.

When the camera boots up and you get the Chinese menus, what can you do at the serial console?
Is there a usable shell?
If so, is there a tftp command?

Well in my haste I tried doing what I thought was the manual MTD hack and may have made the situation worse. I confused mtd6ro with mtdblock6 and modified the wrong file.

I entered a Telnet session and made a copy of mtdblock5 and mtdblock6 using my network storage mounted on nfs00 using "cat /dev/mtdblock6 > /mnt/nfs00/mtdblock6_orig and same again for mtdblock5 but not sure why I needed that one.

I modified a copy of mtdblock6 using the instructions contained in the Brickfix and then wrote the modified mtdblock6 back to /dev/mtdblock6. The contents was exactly the same as mtd6ro so I thought I had the right files.

Reboot and now it seems I've broken it again. In a boot loop but able to interupt boot to access a shell prompt and HKVS# prompt but now that I've lost connection to my network storage, I am not sure how to put back the original mtdblock6 without the network mount.

I should have made a local copy on the device itself. I know that now.

I have shell access and seems like i have tftp command but I dont seem to have a working network interface that I can figure out. I assume if I can work out the network interface I could use tftp to reload the original mtdblock6 back?

 

[alastairstevenson]

same again for mtdblock5 but not sure why I needed that one.

No, you don't need that.

able to interupt boot to access a shell prompt and HKVS# prompt

I have shell access and seems like i have tftp command

This is the HKVS # prompt at the bootloader?
In theory with tftp and nandread / nandwrite you can import and export and read and write flash data.
But I don't recall if nandwrite works in blocks or bytes, so that may be a bit risky.

Is there any obvious reason in the console log why the device is rebooting?
Maybe zip up and attach your mtd6ro_orig and mtd6ro_mod and I can check them.

If the last firmware version that was applied was the 5.1.6 then one possible way to get to a good enough environment to operate on mtd6 would be to try for a root shell.
Here is what should work, after interrupting the bootloader :

setenv bootargs console=ttyS0 initrd=0xc0a00000,0x400000 rw root=/dev/ram dbg=9 debug single
saveenv
reset

Then, if it boots to a shell prompt, some initiallisation commands (change IP address to suit) :
/bin/mount -t proc proc /proc
/bin/mount -t sysfs sysfs /sys
/bin/mount -t ramfs ramfs /home
/etc/S_udev
ifconfig eth0 192.168.1.64 up

With luck, at that point you could mount your network share as you did before.
By the way, /dev/mtdblock1 holds that last update status, and if the data suggests it failed, it triggers a reboot, which would then loop.
Some original 5.1.6 cameras held values there that caused bootloops when newer firmware was applied, that's why the original mtd hack needed mtdblock1 to be checked and maybe modded.
The brickfixV2 method automatically applied a valid template to mtdblock1
I don't think that's likely to be a problem with your camera, but if you can, try to grab a copy of mtdblock1 for inspection.

 

[venturis]

This is the HKVS # prompt at the bootloader?

Yes, I was also able to break the boot sequence with a Ctrl-c and was dropped into a shell prompt.

There seemed to be lots of errors being thrown up during the boot sequence when monitoring from the console. Nothing that I could put my finger on. After a short while the device dropped into the shell prompt and after a few minutes of inactivity it would try rebooting again.

From the shell I was able to poke around the camera but I couldn't for the life of me work out how I was going to import my original mtdblock6 without a functioning network connection.

Only when you prompted me with the "ifconfig eth0 192.168.1.64 up" did the light bulb turn that it was what I needed to get the network connection running with a valid IP address.

After that, I was able to tftp over from my PC the original mtdblock6 that I'd backed up earlier and wrote it back to the device.

After a reboot, a sigh of relief when I heard the "click" of the IR filter during the camera power up which was a good indicator that it was working again.

I'm now literally back where I started 3 days ago although its' been a terrific learning exercise.

As far as the mtdblock1 is concerned. The original attempt to apply the Brickfix v2 never got past stage 1. The camera borked on the very first attempted reboot after the brickfix was applied via the tftp update. Could that mean that mtdblock1 was not updated with a valid template as you suggest?

I've attached a copy of the relevant mtdblocks.

I don't understand what the difference is between say mtdblock6 and mtd6ro. They appear identical. When applying the Brickfix V2 I updated the mtd6ro but from what I can glean form reading the various posts on the subject when doing the manual brickfix that I need to modify mtdblock6 and mtdblock5 and write them both back to the camera.

 

[alastairstevenson]

There seemed to be lots of errors being thrown up during the boot sequence when monitoring from the console.

Yes - this can be quite confusing. Mostly they are notifications, even though they are labelled as errors.

Nothing that I could put my finger on. After a short while the device dropped into the shell prompt and after a few minutes of inactivity it would try rebooting again.

This was after you changed the bootargs value? That worked OK then.
It will do a timed reboot when the watchdog timer runs out, as it's not being fed to keep it going.

After that, I was able to tftp over from my PC the original mtdblock6 that I'd backed up earlier and wrote it back to the device.

That's good.

As far as the mtdblock1 is concerned.

The one you extracted looks OK. The location 0x0C holds one of the update success counts, as long as it's not 0 that's OK, so no changes needed.

I don't understand what the difference is between say mtdblock6 and mtd6ro. They appear identical

They are identical - it's the same flash area, just the different opening modes. mtd6, mtd6ro and mtdblock6. Character device, read-only to avoid locking conflicts when another process has it opened for write, and block device.

I've attached a copy of the relevant mtdblocks.

But presumably not the modded version, which would be the one to check.
The only change needed from the original is the language byte and the checksum, the devType is OK.
Modded version attached.
You don't need to do anything with mtdblock5, it's not used for this purpose.

Don't forget to put the bootargs value back after you are done writing mtd6ro_mod back.

 

[venturis]

Well that really takes the biscuit.....the modified copy mtd6ro you supplied worked a charm. Dropped it back into the cam, reboot and away it went.

I re-flashed the firmware with an English version of 5.1.6 taken from Hikvision.com some time ago and it went on without complaints.

The really frustrating part is that I compared your copy of mtd6ro with the one I produced that caused problems and they are for all intents identical.

Something clearly went wrong when writing back to mtdblock6 on the previous occasion since the camera recovered only once I restored the original backed up version.

To check I hadn't just been lucky, I threw caution to the wind and updated my 6th and final 2cd3332 by extracting mtd6ro, doing the language byte and checksum change before writing back to the camera. This time it was flawless. Took all of about 2 minutes as opposed to the two days to head scratching that the previous cam had involved.

Thank you very much Alastair for your valuable assistance, without which I would have bricked camera.

Not that it was worth much, it would have annoyed me however that I'd broken a working camera and knew that with persistence and a lot of help, it could be fixed. If nothing else I've learned something new.

Thanks again.

 

[alastairstevenson]

Well, that's a good result, I'm pleased you got there.

Not that it was worth much, it would have annoyed me however that I'd broken a working camer

Yes, I know that feeling, and the desire not to throw it away.
As you say, it's all part of a learning experience, and helps keep the mind active and engaged.
Which we really need in the current strange situation the whole world is in.