News:

Registered a URL and setup a forum as the IPCam stuff really needed its own site vs my irregular blog posts about IPCam hacking at http://www.computersolutions.cn/blog

Author Topic: Firmware Recovery - method #2  (Read 107904 times)

  • *****
July 22, 2011, 05:50:37 pm
Take a look at the wiki page (http://wiki.openipcam.com/index.php/Serial_Console). White should be common and green Tx. It is possible that the manufacturer could substitute colors but your's sounds the same as the wiki.

July 27, 2011, 04:52:44 pm
Thanks celem.

I didn't get any log from kermit or putty. In putty I just set /dev/ttyUSB0 and 115200 and then rebooted foscam but I didn't get any log from foscam. I connected white->pin3, green->pin2 and blue->pin1. Here is picture from foscam 8918 serial connector: http://dl.dropbox.com/u/25577/Foscam/IMG_1929.jpg or http://dl.dropbox.com/u/25577/Foscam/IMG_1881.jpg
Are those two lines (from mcu to J2) really rx and tx in foscam 8918?

This is system log from ubuntu when I connected usb to vmware:
Jul 27 12:04:06 ubuntu kernel: [290705.960331] usb 2-1: new full speed USB device using uhci_hcd and address 7
Jul 27 12:04:06 ubuntu kernel: [290706.664592] pl2303 2-1:1.0: pl2303 converter detected
Jul 27 12:04:06 ubuntu kernel: [290706.720468] usb 2-1: pl2303 converter now attached to ttyUSB0

  • No avatar
  • *****
July 27, 2011, 05:50:11 pm
Hi,
try connecting green and blue, this should echo your typed characters on the screen in putty.
If not, try conecting two other colors (only 3 possibilities). If you find a working "pair" you know the left over one is gnd. If it doesn't work at all, you know that the config or cable is wrong...

July 27, 2011, 06:07:39 pm
Ok, will try.
Now I read your older post, and saw that 10 is tx and 11 is rx and I ha reverse connection. Now I tried again with the new connection and in kermit I got strange symbols and in putty cursor is just moving.

edit: same strange symbols if connect green and blue:
http://dl.dropbox.com/u/25577/Foscam/log.png
« Last Edit: July 27, 2011, 06:35:33 pm by BlackCam »

  • *****
July 27, 2011, 10:07:06 pm
I've attached a markup of your pix showing what I think your pinout is. Your symbol text  output looks like either (1) the Rx is floating and not pulled high. The photo clearly shows that R40 is a pullup for just that purpose; (2) Your RX/Tx leads are attached to the wrong pins, i.e. reversed; (3) your Ground is missing, making the Rx/Tx float without a reference. Are you on the correct pin for ground?; (4) Your baud rate is NOT 115200, which, while unusual, is not impossible.

  • No avatar
  • *****
July 28, 2011, 01:44:52 am
if he gets only garbage when he just connects the rx/tx from the cable (without any other connections involved) then he has serious problems with either the cable or putty ... maybe try again with a lower baudrate

July 28, 2011, 05:22:51 am
if he gets only garbage when he just connects the rx/tx from the cable (without any other connections involved) then he has serious problems with either the cable or putty ... maybe try again with a lower baudrate
Now I installed pl2303 driver to osx, then took connection in osx and it seems to work (receiving log in startup) :)
Later today I will try to backup firmware.
Thanks for your help!

If someone also need, I downloaded osx driver from here: http://osx-pl2303.sourceforge.net/
« Last Edit: July 28, 2011, 05:29:35 am by BlackCam »

July 28, 2011, 06:26:40 am
I've attached a markup of your pix showing what I think your pinout is. Your symbol text  output looks like either (1) the Rx is floating and not pulled high.
Does it mean that I can backup firmware, but not restore it?
Quote from: celem
Are you on the correct pin for ground?; (4) Your baud rate is NOT 115200, which, while unusual, is not impossible.
Yes, I connected correct pin for ground.

  • No avatar
  • *****
July 28, 2011, 07:26:03 am
If you can see characters, and can type characters that display on the bootloader or os, then its connected up ok.

Make sure that you set the buffering correctly in the driver settings, as the pl2303 is a bit crappy for that.

July 28, 2011, 06:27:24 pm
Make sure that you set the buffering correctly in the driver settings, as the pl2303 is a bit crappy for that.
I did it like it was mentioned in wiki, but I don't know about buffering or I don't understand.
If I take a dump, it usually stop (or freeze) with the size <0x10000. Could it be because of pl2303 buffering or because my cable is too long (http://dl.dropbox.com/u/25577/Foscam/IMG_1928.jpg).
Or maybe it is better to buy better usb ttl serial converter?

  • *****
July 28, 2011, 07:36:05 pm
Are you using a VM? If so, that may be a factor. I use the inexpensive dealextreme USB fake-Nokia usb serial cable and have not dropped a bit yet. Consequentially, unless your USB serial unit were defective, it is more likely due to some driver issue. I believe that ADMIN previously said that he uses a true serial port, not a USB converter because he had similar problems. You might try that if you cannot resolve your dropped bits.

The IP-Cameras do not support flow control so your PC has to have enough horsepower to handle the 115200 baud data at full speed, plus whatever else it is doing. I run a quad-core box e/w 64-bit Linux.

  • No avatar
  • *****
July 29, 2011, 02:04:07 am
for a start I would eliminate the alligator clips. Twist the cables and secure with tape or better solder them.

Second I'd try to use Xon/Xoff software handshake. Sometimes the device specific drivers do support it.

Then you could try to set a lower baudrate; first on cam (see the set command), then in terminal.

unfortunately I don't know what options the pl2303 drivers on OSX support.

August 04, 2011, 10:07:23 am
Celem: No I didn't use VM, because the result was like this: http://dl.dropbox.com/u/25577/Foscam/log.png.

I tried Xon/Xoff handshake, first it seemed better (I got over 0x30000) but after second try not. I tried also with lower baud rates, but I didn't get any better result. Currently I don't have any laptop with serial port, so maybe I have to take risk and update a modified firmware (newest official firmware + telnetd bin).

osx_pl2303.cpp file is somehow inspired by linux kernel PL2303.c. I took osx version from svn. If I have time, I will also take linux version and compare them together.

  • *****
August 04, 2011, 11:08:32 am
If lower baud rates did not help, I still suspect either that your connection has a floating reference, meaning not wired correctly to GND, Tx, RX, especially the GND. If the Rx is floating without a reference you'll see such garbage. Disconnect the cable, insert a pin into the socket's GND socket and, with a ohmmeter, measure the resistance from the DealExtreme serial interface cable's white wire to the pin in the socket's GND socket, checking for a broken wire or poor connection. It should be zero ohms. Test the other leads also - but I suspect the ground reference the most.

The DealExtreme cable's white wire should be connected to the camera's Ground/Common. Normally, the common is on pin 3. The square pad indicates pin 1. The Tx lead, which should be the DealExtreme cable's green wire, should normally be connected to the camera's pin 4 and the DealExtreme cable's blue wire, should normally be connected to the camera's pin 3. The camera's pin 1, the one with the square pad, should have no connection.

Of course, your DealExtreme serial interface cable could simply be defective.
« Last Edit: August 04, 2011, 11:10:20 am by celem »

August 08, 2011, 03:29:10 pm
Now I got it. When dumping was paused I accidentally touched the cable with a screwdriver and after a while it continued. It took very long time because I had to be touching cable.
I suspect that the issue was in dx cable or driver. Of course it could be ground issue or sum of several issues.