GPIO and Camera executable reversing.

I guess that I never really noticed this thread before but I can add something useful - I think. Lately I have been working with Arduino boards and now the raw Atmel chips. During some of my testing I experimented with some inexpensive Chinese 5V stepper motors that are primarily used in HVAC equipment to move vanes to change airflow direction. They are readily available on eBay (see: http://tinyurl.com/7l6torx). They are almost identical to the steppers found in IP-Cameras with the only significant being a slight difference in diameter by just a few millimeters. They are very easy to operate and have quite a lot of torque - several pounds of torque. You can read all about how to operate them from software at my post on the Arduino forum, here:
http://arduino.cc/forum/index.php/topic,85335.0.html

thanks for the help...I'll take a look at that info.
however, I still dont really understand what is going on with the 'addressable latch' that's being discussed in this post. can you provide some help on figuring this out please?

It is a shift register, which thus requires fewer I/O pins from the CPU. Data is shifted in as serial data, then the latch is enabled, presenting the data as parallel to the stepper. The purpose of the shift register is simply to reduce the amount of I/O needed from the CPU. The addressable part is that this particular shift register contains multiple registers that can be individually addressed. I haven't used this particular part - way to complex for my needs. A simple, one register, 74HC595 suffices for my needs.

Ive been bashing my brains out trying to get this to work.
I finally managed to understand how to use the gpio ports on the W90N745...
I put together some code that in theory would configure gpio pins 7-10 (pins #2-5 of gpio port#5) and then set each pin high&low.

however, it looks like theres more going on here than simple gpio calls.
no matter how I tried, I could not set physical cpu pin #12 (gpio port#7) to 'low', and, in fact, it is at 3.3V by default. I checked the voltage even while at the bootloader prompt (i.e., before loading linux), and its also at 3.3V...I tried loading both my custom 3.1 kernel, and the 2.4 kernel from the BSP, and got the same results; cpu pin #12 stuck at 3.3V, and any attempt to try to reconfigure and change the datavalue failed or was simply ignored, the voltage was stuck at 3.3V (this is the pin that goes to the 'A0' input on the addressable latch).

so, I loaded up the default kernel, and placed my meter probes on pin 'A0' while the kernel booted.
At around the point mentioned at the beginning of this thread, when the camera exe is running and prints out "no support" and does the usb initialization, the voltage on the pin drops to 0.2-0.3V.
From what I understand, there's no way that pin A0 on the latch should be the source of the 3.3V, so pin 12 on the cpu is definitely the source of the 3.3V, is this correct?

based on the info gathered by 'admin' in the first post, only gpio ports 0 and 4 are being initialized, so what the heck is going on with cpu pin 12 (which corresponds to 'gpio7/gpio port 5 - pin 2')? So, clearly something in the camera executable is resetting this pin and getting it ready for IO, but how is this being accomplished???

another small thing that I realized is that, in the datasheet for the N745, the section on gpio shows the text 'need updated' next to the description for gpio port 5 (see page 314 of the data sheet). So, now Im wondering if there have been drastic changes in the specs for this chip with regards to gpio port 5???

anyway, Im completely stuck, so I would really appreciate some help on this...
admin, where are you??? please save me...

according to the datasheet it has double funtion as UART1/TxD.
Maybe this serial port gets auto detected and initialized (even with login waiting).
Look to disable it in kernel or maybe there is way to disable UART1 in cpu init (CLKSEL register).
Maybe there are some hints in examples of SDK

ok, i finally did manage to control the voltage on the GPIO port 5 pins, but something still isnt right about all of this...

I tried using the method mentioned above, to control the output to GPIO pins 7-10 (assuming addressable latch mode) but it didnt work at all. In fact, now Im wondering if its even using addressable latch mode at all? are we sure its not just using the 3-8 demux mode? In any case, it seems necessary to be able to control pins 13&14 on the latch, but the info posted above assumes that these pins are not attached to any of the cpu pins (which I believe might be wrong, but I need help confirming this). I built a small test program that configures the pins and loops over the different outputs, but it didnt work. Id be willing to post the code for my test app if anyone is interested.

The datasheet for the latch states something about having to force a 'low-to-high transition' on the 'LE' pin (input pin 14 on the latch) in order for the changes on data input on the addressed pin to take effect.
from the latch datasheet:

Code: [Select]

d = HIGH or LOW data one set-up time prior to the LOW-to-HIGH LE transition;
q = lower case letter indicates the state of the referenced input one set-up time prior to the LOW-to-HIGH transition.

'd' being the data input on latch pin 13
'q' being the values on the latch output pins 0-7

I might be confused about how this works (this is honestly the first time Ive ever tried to work with this stuff / latches), but based on that it would mean that we require control of pins 13&14 in order to properly manipulate the latch outputs. is this correct? can someone please either help clarify this or confirm my findings?

I think the biggest problem is that I cant fully trace the latch inputs to the cpu; the wireless board on the underside of the main board is in the way of seeing where input pins 13&14 are attached to (I cant follow the circuit connections once they jump to the underside of the board, theyre hidden under the wifi add-on board). I think that the wifi board would need to be temporarily removed in order to fully identify how the connections are setup. Unfortunately, Im not brave/confident enough to desolder & resolder the wifi board on my camera. would someone be willing to help with this, or can someone think of an easier way to identify with 100% confidence the circuit layout for the latch-to-cpu connections? Again, I have serious doubts that the connections listed in this post are 100% correct.

Im even starting to doubt where gpio pins 8&9 go.
According to this post, pins 7-9 go to input pins A0-A2 on the latch.
but Im only able to physically verify that gpio pin 7 goes to input pin A0 on the latch; the other 2 pins dip under the latch and I cant really be sure that theyre really going to input pins A1 & A2 on the latch.

The only tool I have to test the circuit is a digital volt-meter, so its tough figuring out what's going on electrically with the gpio pin outputs & latch inputs. I tried loading the default firmware, and checking the voltages during the camera's pan/tilt movement, but havent been able to determine anything *that* helpful (im guessing that the voltages on the pins alternate on/off so fast that the volt-meter cant really pick up the changes well enough and instead has to 'average' out the values, which makes it more difficult to clearly understand whats really going on). The only 'sure' thing that I was able to determine are that latch outputs 0-3 control the camera's 'tilt' movement and latch outputs 4-7 control the 'pan' movement.

So, I really need some assistance with this; Im clearly stuck, and it doesnt seem like anyone else is very interested in getting the pan/tilt functionality to work. It seems strange that this is the case, since this is the only thing really standing in the way of getting a true fully featured, open-source firmware for the 541 cams.

can someone *please* help me out with this? thanks...

one other possibility would be to "reverse engineer" the stepper routines from the disassemled camera binary that is available in the files section. Not easy but something that can be done without soldering iron 

well, thats basically what admin did all along this post...
the problem is that it doesnt appear to be in the cam executable, its in the kernel driver (/dev/ptz0).
I even tried running the 'arm2html' decompiler on the actual 'linux.bin' kernel image, but it didnt work.
if someone else can recommend a good way to decompile the kernel code and figure out whats going on with that '/dev/ptz0' driver, that would be awesome...I really dont have much experience looking at assembly code and trying to decipher it, so I need someone's help with this.

bump...anyone??? admin??? please, Im desperately trying to get this to work in order to move on with developing a custom kernel.

i dont understand why no one seems to be taking this aspect of the project seriously. it seems like no one really cares about getting the pan-tilt functionality to work. Its ironic, because there's really no point in having a 'custom firmware' project that doesnt even provide full functionality to the camera if we're never going to find a way to get the pan/tilt motors working. so what is going to be done about this??? admin??? anyone???

whats the status on all of this? admin? are you there? can you please help?
Has anyone been able to work on GPIO/ptz driver? can anyone please volunteer to help out?
I havent been able to do much more with this, I hit a dead-end and couldnt really accomplish much more than what Ive already listed. Please, someone with more hardware experience help me out with this...

Hi changosurf, I am also very interesting on making a custom driver for the PTZ (though there's no Zoom in my cameras).

I have my final exams now, but probably I will be active around here in two-three weeks.

Id be willing to post the code for my test app if anyone is interested.

Your code would be really helpful as a start point for this driver.

I put the ipcamera work down for a few months, but now Im ready to begin again...

The unresolved issue with getting the GPIO control working for the pan/tilt motors is essential, and it seems strange to me that no one seems to be working on or care about the GPIO functions (or perhaps they've already found a solution but they're simply not sharing the info). Without being able to control the pan/tilt, the entire openipcam project is completely pointless.

In fact, I keep thinking that this project is dead altogether, since people don't seem to be posting new, productive stuff on the forums. The only activity that seems to occur is from random people that have somehow bricked their ipcams and are trying to find & download firmware for misc. cloned models. Its a shame, since this really has the potential to be a pretty cool platform to build upon. The site admin seemed to be the most knowledgeable about the camera architecture, but he/she doesnt seem to be willing or able to help anymore either. But I digress...

Im attaching a few 'scratch' source files that I had developed a few months back when I was playing with the GPIO code. You'll have to decipher whats going on and look at the datasheets for the W90N745 and the addressable latch to figure out what I was trying to accomplish. Anyway, even though it doesnt work, at least its *something* to start with (I havent seen anyone else try to provide some actual working code, and Ive asked admin for assistance a few times but have never received a response). Again, its scratch code, so you'll have to figure it out. Also, you'll have to figure out how to integrate it into your build environment for the ARM arch./custom uClinux kernel.

hope this helps, and if anyone manages to get something working or make some progress please post back and let me know (since apparently Im the only one trying to get this to work).

You might find this useful (depending on how mangled staff have made it in my absence).

https://github.com/openipcam/openipcam-n745-2.4/blob/master/BSP/ucLinux24BSP/uClinux-dist/user/gpio/gpio.c

This is more for printing GPIO data, and poking / peeking from specific locations, but it is useful for those looking at that kind of thing.

ok, i got started on this again and have made a little bit more progress.
using the code example from the git repository that admin posted above, i managed to build the 'gpio tester' executable and load it onto the existing factory firmware.

However, I added the following routine to be able to monitor pin values on GPIO port#5

Code: [Select]

void show_c(){
int i;
printf ("\n");
while(1){
i = inpw (0xFFF8305C);
int j;
for(j=0;j<13;j++){
printf("%d ",bit_value(i,j));
}
printf ("\n");
}
}
I also added logic to allow for an extra command arg '-c' (not shown).
I then ran the tool,'gpio_tool -c', while at the same time setting the camera to 'patrol' pan mode, panning both vertically and then horizontally...

here's some random sample output from the command while the camera was idle:

Code: [Select]

0 1 0 0 0 0 1 1 1 1 1 1 0
1 1 0 0 0 0 1 1 1 1 1 1 0
1 1 0 0 0 0 1 1 1 1 1 1 0
0 1 0 0 0 0 1 1 1 1 1 1 0
1 1 0 0 0 0 1 1 1 1 1 1 0
0 1 0 0 0 0 1 1 1 1 1 1 0
1 1 0 0 0 0 1 1 1 1 1 1 0
0 1 0 0 0 0 1 1 1 1 1 1 0
1 1 0 0 0 0 1 1 1 1 1 1 0
0 1 0 0 0 0 1 1 1 1 1 1 0
0 1 0 0 0 0 1 1 1 1 1 1 0
1 1 0 0 0 0 1 1 1 1 1 1 0
0 1 0 0 0 0 1 1 1 1 1 1 0
1 1 0 0 0 0 1 1 1 1 1 1 0
1 1 0 0 0 0 1 1 1 1 1 1 0
1 1 0 0 0 0 1 1 1 1 1 1 0
1 1 0 0 0 0 1 1 1 1 1 1 0
0 1 0 0 0 0 1 1 1 1 1 1 0
0 1 0 0 0 0 1 1 1 1 1 1 0
1 1 0 0 0 0 1 1 1 1 1 1 0
0 1 0 0 0 0 1 1 1 1 1 1 0
0 1 0 0 0 0 1 1 1 1 1 1 0
0 1 0 0 0 0 1 1 1 1 1 1 0
0 1 0 0 0 0 1 1 1 1 1 1 0
0 1 0 0 0 0 1 1 1 1 1 1 0
1 1 0 0 0 0 1 1 1 1 1 1 0
0 1 0 0 0 0 1 1 1 1 1 1 0
0 1 0 0 0 0 1 1 1 1 1 1 0


Here's what I discovered as I watched the pin-value output:
1) pin '0' constantly changes in value, even when the camera is idle(no pan/tilt movements ocurring, see the sample output above...)

2) when set into 'vertical patrol' mode, pins #4 and #5 start showing activity
sample output:

Code: [Select]

0 1 0 0 1 0 1 1 1 1 1 1 0
0 1 0 0 1 0 1 1 1 1 1 1 0
1 1 0 0 1 0 1 1 1 1 1 1 0
0 1 0 0 1 0 1 1 1 1 1 1 0
1 1 0 0 1 0 1 1 1 1 1 1 0
1 1 0 0 0 1 1 1 1 1 1 1 0
1 1 0 0 1 0 1 1 1 1 1 1 0
1 1 0 0 1 0 1 1 1 1 1 1 0
1 1 0 0 1 0 1 1 1 1 1 1 0
0 1 0 0 1 0 1 1 1 1 1 1 0
0 1 0 0 1 0 1 1 1 1 1 1 0
0 1 0 0 1 0 1 1 1 1 1 1 0
1 1 0 0 1 0 1 1 1 1 1 1 0
0 1 0 0 1 0 1 1 1 1 1 1 0
0 1 0 0 1 0 1 1 1 1 1 1 0
1 1 0 0 1 0 1 1 1 1 1 1 0
1 1 0 0 1 0 1 1 1 1 1 1 0
0 1 0 0 1 0 1 1 1 1 1 1 0

3) upon reaching its lower vertical pan limit, pin#10 briefly goes from '1' to '0' for approx. 16 iterations of the value-select loop

4) same as point #3 above, but on the camera's upper vertical pan limit, pin#8 goes from '1' to '0'

--> based on points #3 & #4 above, Im guessing/assuming that these pins are somehow being used to notify the camera that its reached its limit and needs to start spinning the motor in the opposite direction.

5) during 'horizontal patrol' panning, things are completely different. none of the pins in the 6-12 range show any activity. pins #4 & #5 are also idle/show no activity, so it *seems* like the controls & limits for the horizontal panning are being handled somewhere else and not on these pins?

6) the constant activity on pin #0, and then also the activity on pins#4&5 makes me wonder if the cam ptz driver is operating the chip's pins in UART mode instead of standard GPIO mode? Im not knowledgeable enough about this stuff yet to make that determination, so Id appreciate some help/guidance on this...

- I realize that my 'rigged' infinite-loop value-probing routine probably sucks pretty badly and isnt an ideal way to do this kind of thing, but I couldnt think of anything else. I basically needed some way to monitor activity on all of the pins in 'realtime' in order to check for changes while the camera was in motion...if someone else can suggest a better way to setup a 'pin monitoring tool' Id really appreciate it...

Just adding a note on this post to mark the issue as 'solved/closed'.
For more info on the solution found for control of the stepper mootors (and camera indicator LED) via GPIO, check the following post in the 'Hacking & Modding' forum:

http://www.openipcam.com/forum/index.php/topic,586.0.html