Tag Archives: logic sniffer

Hello Caller, You Are Through To The Helpdesk Part2

Hands up who thought I would have fixed it by now. You are not alone, I figured this would be an easy fix too. If you remember last post (or care to click on previous post), you would remember that I was concerned by those few pins that looked damaged. Well damaged they were, and a quick touch-up with a soldering iron soon fixed that problem. Did I say fixed; I clearly meant changed.

I have jumped the first hurdle, only to be greeted by a brick wall. Yes, I can see more of the flash. No, the flash is not complete – or at least it is corrupt. I will take this opportunity to thank the people over at http://www.openipcam.com as they have been/are being fantastically helpful. It is pretty obvious that the Flash chip is responsible for all my woes – and also for forcing me to understand ARM processors a bit more. These work differently to how a PIC or Atmel (including the arduino) works. The 4M flash chip is split into a number of sections; the bootloader, uCLinux, the file system, and additional settings or website interface. The ARM takes these pieces of data and copies them onto the 16M SDRAM chip, and runs the software from there. This realisation led me into thinking of this tiny embedded system as a mini-computer instead of a microcontroller; something that I am sure is either entirely obvious to people, or lost on them. Either way, my thinking had changed.

I still had a problem that needed breaking down and I came up with a number of different theories. Either the ARM, flash, or SDRAM couldn’t communicate properly, or the flash had gotten corrupted. I knew that some of the flash was fine, and some of the communication was working as I already had the bootloader loading up, and now I could see what was actually in the flash. However, I couldn’t trust anything I was seeing from the flash, as I knew part of it wasn’t working. If only there was a way to load the SDRAM directly. Luckily we can do just that.

Using the command “mx 0x8000” it is possible to upload a version of uCLinux directly into SDRAM, and “mx 0x700000” allows us to upload a new file system. On XP this is easy. All I need to do is open HyperTerminal, click Transfer -> Send File. All I needed to remember was I was using the XMODEM protocol. HyperTerminal was actually written by a company called Hilgraeve, and was licensed to Microsoft to use in their communications package. Apparently Microsoft did not want to continue paying a fee for this incredibly useful piece of software, and so HyperTerminal is no longer packaged with either Windows Vista, or Windows 7. To get around this, I used RealTerm as my serial communication program, and fall back on TeraTerm when I need to use the XMODEM protocol. These tools are purely my preference, and not the only ones capable. Uploading the two files takes some time, but once they are done all that was left was to type “g 0x8000”. This tells the ARM to start running whatever is found at data position 0x8000, which just happens to be where I stored the uCLinux program. I was able to ping Google, and so I was happy that the SDRAM was working properly, and I started on the long journey on sorting the flash out.

People always talk about data as “ones and noughts”, or “zeros and ones”. This is fine as that is how a computer stored that data – but it is not how the data is represented. Letters are just a collection of straight and curved lines, and yet we that is not how we think of them. I am not going to go into bytes, nybbles, hexadecimal as you already know it, or you don’t want to know it. I will say that the flash chip has numerous address and data lines; the idea being you punch in the address that you want and the chip will pump out the data held in that address. The “ones and noughts” become important now as they make or break those address and data values. Imagine we wanted data location 13. This becomes 00001101, so we would set our address lines high or low depending on those values. Now unfortunately we have a fault on the board such that bit5 is always tied high. Although we want 00001101, the flash chip sees 00011101 (or location 29) and gives us the data held in that location. This works the other way too, as writing to location 13 would not only overwrite location 29, but also leave 13 alone. There is no easy way to diagnose these problems, other that a multimeter and a steady hand. Alternatively, I could solder flying leads to each of the pins of the flash chip, and the appropriate pins on the ARM, and check the transitions with my Open Bench Logic Sniffer.

Again, if you checked my last post, you would see that I gave up on using the Logic Sniffer. Or should I say I gave up on it for the night. The next day I took it to work, followed the same steps and “hey presto” it worked first time. I am now running the latest PIC and FPGA code, and it works great…at work. For some reason, it still doesn’t play nice with my home PC. There must be some quirk with the combination of Windows 7 and a 64bit OS that means it just won’t play nice. It appears as a comms port, but software doesn’t appear to be able to talk to it. I am chalking this up to be an issue with the Microchip drivers, as I can’t open the port in any other program either. I went as far as downloading Microchips latest Application Library (containing the latest USB Framework), in an attempt to get a working virtual com port, but even that didn’t work.

Moving back to the camera. Although the boss is aware that I am bringing this problem into work, I set it apart just for breaks and lunch time, and the occasional early start and late finish. As part of the process I have had to take the PCB out of the case. This makes probing a lot easier, but also has the added benefit of disguising its true purpose if the MD walks past my desk.


Hello Caller, You Are Through To The Helpdesk Part1

I was getting ready to have an enjoyable weekend catching up on my free Stanford University courses when I received a phone call from my father-in-law. This usually means that some piece of technology has gone wrong and I take the role of helpdesk.  Before you all start drawing conclusions from this; he is fairly technical and so this call means something has gone seriously wrong, and I actually enjoy these challenges. Today’s challenge was a no-name pan/tilt IP Camera.


The first step to troubleshooting a problem is to isolate and repeat it. Normally upon power-up the camera would perform a single sweep on both axes, and sit in a centre position. This was not happening – so either the thing wasn’t powered, or the firmware wasn’t running. Plugging a network cable in lit up the status and activity LED’s so at least we knew that it was getting power. I didn’t really want to open the camera yet (purely as it wasn’t mine), so opened up AngryIPScanner and Wireshark. I couldn’t find the device on any subnet despite the activity light flickering. There was no other option, I had to crack this bad boy open.


There are a number of chips on the PCB (# ESTESPCB613M136) , including a Nuvoton W90N745CDGARM (main ARM processor), Winbond W9812G6JH (2M SRAM), DM9161 (phy chip), and a WM8731 (audio codec). The other side included a Stansion S29GLO32 (another Flash chip) and a WiFi daughter-board. All in all, not an overly complex board. Due to a poor design choice, the threaded mounting hole is directly above the ARM chip. There was a light witness mark on the ARM, but I was more concerned by the marking on a number of pins – almost as if the solder was squashed. Unfortunately, I don’t have a decent iron at home, so a fix will have to wait until I get back to work. I turned to Google to get more information on the camera. I didn’t have access to the box, so I had no idea who the manufacturer was, but I found out that Foscam used to OEM extremely similar looking cameras in the past, and the likelihood is that this is either one of the OEM variants or a clone thereof.

A typical feature of the Foscam camera range is the presence of a UART header connection, and this was no exception. Although it wasn’t labelled, a quick check of the N745 chip datasheet identified the pins as thus. This enables a terminal connection to the ARM’s bootloader upon power-up. I was using my only remaining Max232 in a different project so I took the opportunity to revive my Open Bench Logic Sniffer. It needed updating to bring it to the current revision, but once that was done I could start on the hard stuff. And here we hit a snag. I updated the Logic Sniffer, and now the USB won’t enumerate. Clearly I am not having a very good day.


So before I could start fixing the IP Camera I had to now fix my Logic Sniffer. This was as easy as soldering some header pins to the ICSP and use my PICkit3 to reprogram the PIC. And by easy, I meant I gave up and hit the forums. I had to resort to hunting down my old PICDEM 2 PLUS board (circa 2002) and use the MAX232 onboard. I had to use the same trick to get the keys off my 360 DVD-drive, but that is another story. With fresh wires soldered onto the camera board, and plugged onto the PICDEM2 board, I loaded up RealTerm. Powering up the camera board revealed that the ARM is working (at least part of it), as I get a nice serial interface.


Routing around in the terminal revealed that only the bootloader is present, and there is no sight of the linux.bin or romfs.img files that I was expecting. Given this I can draw one of two conclusions; either the data on the flash chip has become corrupt, or the pins with witness marks are actually broken and the ARM can’t talk to the flash chip.

Stay tuned for Part2, where we find out if the camera can be recovered.