Digi ConnectMe Notes

2007/8 Update

2008-12-28T17:48:00.000-08:00

I still get inquiries about ConnectMe. This year, I worked three ConnectMe projects for different customers:

1. Rapid application development framework in NetOS 7.4 and ESP. I set up the AWS web pages and some other tricky stuff, and provided hooks for the client's backend code.

2. Socket code debug, in NetOS 7.0 command line. This customer just needed help getting various examples working together.

3. Recovery of loadable modules from multiple unsynchronized source trees in NetOS 6.0f command line, and detailed manufacturing instructions, for a company that had lost touch with its original ConnectMe specialist.

I post on the Digi support forums as lslarry86.

Happy New Year to all,

Larry Martin
www.GlueLogix.com
Copyright (c) 2008 Larry Martin. All Rights reserved.

Digi Boot Loader

2005-01-26T18:30:00.000-08:00

The S-type Digi boot loader is not the same as the one in the NetOS source tree. Digi has not published the source but, according to Digi tech support, there are two ways to recover bad-download modules using the Digi Boot Loader:

1. Upon module power up, if the boot loader determines that the application image is missing or corrupted it attempts to retrieve a replacement image, via TFTP, using the TFTP server address of 192.168.0.128 and a filename of 82000856. I have not observed this behavior. My Ethereal shows no activity on TFTP port 69; however, there could be a problem with netmask, etc., keeping me from seeing these packets.

2. If ConnectMe pin 18 is grounded at powerup, the boot loader puts out a menu at 9600N81 on the normal serial port. The menu lets you set up IP and netmask, retrieve a file by tftp and load it to Flash. This system works, I have used it on an S-type module that I know to have had its application erased.

Notice that neither of these behaviors is described in the "The Digi CM disaster recovery procedure" which I described in my last post.

Larry Martin
www.GlueLogix.com
Copyright (c) 2005 Larry Martin. All Rights reserved.

Digi Knowledge Base

2005-01-26T06:02:00.000-08:00

Digi has started building a ConnectMe knowledge base (KB):

http://www.digi.com/support/knowledgebase.jsp

This link:

http://www.digi.com/support/kbaseresultdetl.jsp?id=746

takes you to an article titled "The Digi CM disaster recovery procedure". I found the article by searching the KB for "boot loader", with the Product ID set for "Any". When I searched with the product ID set for "ConnectMe" the KB did not show me this article.

While I can't reprint the article here, the gist is: connect a terminal (9600N81) to the broken ConnectMe and press ESCape within 3 seconds of powerup. Then you get a recovery menu. I've heard from Digi tech support that the S-type boot loader is different from the NetOS one. So, presumably, this procedure is only for S-type ConnectMe.

Incidentally, I have tried this and it has not yet worked for me. The problem could still be me. I'll post again when I know for sure.

Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.

The Beginning

2004-11-17T07:18:00.000-08:00

The Digi ConnectMe is an amazing piece of equipment. In a metal can the size of an RJ45 connector, Digi has packed a NetSilicon/ARM chipset including 2 MB Flash and up to 16 MB RAM. The 100BT version draws 300 mA. It costs around US$40 officially, but I've heard of much lower negotiated bulk prices. There is also a WiFi version.

The ConnectMe is basically a LAN to serial adapter. Digi seems to intend that companies buy the device, solder it to their circuit boards, and quickly convert RS232 devices to "internet" devices. That works Ok, but with an ARM and all that memory to work with, it's inevitable that guys like me will try to do something more with it.

Unfortunately, that's where the trouble starts. While Digi has great technical support people, and Ok support forums on their website, I found that their developer support was a bit frustrating. I don't know how other people work, but I need a mental picture of a device before I feel comfortable controlling it. With the ConnectMe, Digi has not provided that. I lost a lot of time going back and forth with their tech support people, trying to figure things out. Finally, the light dawned, and I finished my project.

Now I'll be going through my "old" notes (6 weeks old) and blogging the day-by-day struggle to understand this unique piece of equipment. I hope my readers, if any, learn something for their trouble and share their own experiences too.

FYI, you can skip this entire blog and go direct to the official sources of information:

Digi Connectme website:
http://www.digi.com/products/embeddeddeviceservers/digiconnectme.jsp

Digi Support FTP Site:
ftp://ftp1.digi.com/support/

Digi Developer Forums:
http://www.digi.com/support/forum/

NetSilicon Developer Forums:
http://www.netsilicon.com/netforums/

Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.

The End...?

2004-10-06T20:10:00.000-07:00

It is now two days before my direct customer's ship date, and nine days before their customer's ship date. I have not begun integration testing, mainly because it took so long to get the code loaded. Needless to say, we missed ship time (COB Friday 08Oct04), and I ended up hand carrying the product to my customer's customer, and completing integration phase at their site.

In the end, all the requirements were met and the systems worked pretty well.

For better or worse, it was a successful project.

Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.

Updating S Modules

2004-10-06T19:59:00.000-07:00

Getting to the end now...

The other thing I learned when I started trying to overwrite S modules was that the Standard firmware's update method does not always work. With both Netscape and Internet Explorer, I failed to upload my image.bin file to the Standard firmware's update page:

http://w.x.y.z/admin/upgrade_firmware.htm

Every time, I got the message "Document contains no data"

Tech Support made me try a few more times, then told me that there is an undocumented code update protocol in addition to ftp, tftp and http (the Standard firmware has no ftp or tftp service). They provided me a Windows command line program that implements the protocol - it's called dgdcprog.exe. If you have this problem with S modules, request that program from Tech Support. Here's how to use it:

dgdcprog /discover
(note MAC address in reply)
dgdcprog /set /firmware=image.bin /mac=(MAC from previous reply)

Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.

Discovery

2004-10-05T19:10:00.000-07:00

The Discovery protocol used by Digi's GUI is undocumented. Maybe you care and maybe you don't. Here's why I care. My customer is shipping 99% of their systems with the standard ConnectMe firmware. Around 1% of their systems ship with some cute application that I wrote loaded into the ConnectMe. My stuff has to be visible to the same tools as the standard stuff. But the Discovery protocol is undocumented.

Digi Tech Support says they're working on the doc and it will be ready Real Soon Now. In the meantime, here is an Ethereal capture of a Discovery session between the GUI and a stock Connectme:

=======================================

PC: DHCP IP 192.168.1.103 MAC 00e098:9190ca

ConnectMe S module: fixed IP 169.254.68.244 MAC 00409D:24A790

from PC:

UDP PC port 3326 (0x0cfe) BROADCAST to port 2362 (0x093a)

0000 01 00 5e 00 05 80 00 e0 98 91 90 ca 08 00 45 00 ..^..... ......E.
0010 00 2a 54 f5 00 00 40 11 7e 3e c0 a8 01 67 e0 00 .*T...@. ~>...g..
0020 05 80 0c fe 09 3a 00 16 b6 60 44 49 47 49 00 01 .....:.. .`DIGI..
0030 00 06 ff ff ff ff ff ff 08 0a 00 00 ........ ....

from ConnectMe:

UDP port 2362 to PC port 3326

0000 00 e0 98 91 90 ca 00 40 9d 24 a7 90 08 00 45 00 .......@ .$....E.
0010 00 81 00 0e 00 00 3c 11 cd 5c a9 fe 44 f4 c0 a8 ......<. .\..D...
0020 01 67 09 3a 0c fe 00 6d d7 6e 44 49 47 49 00 02 .g.:...m .nDIGI..
0030 00 5d 01 06 00 40 9d 24 a7 90 02 04 a9 fe 44 f4 .]...@.$ ......D.
0040 03 04 ff ff 00 00 0b 04 00 00 00 00 0d 0f 44 69 ........ ......Di
0050 67 69 20 43 6f 6e 6e 65 63 74 20 4d 45 07 01 00 gi Conne ct ME...
0060 08 1d 56 65 72 73 69 6f 6e 20 38 32 30 30 30 38 ..Versio n 820008
0070 35 36 5f 45 20 30 37 2f 30 31 2f 32 30 30 34 0e 56_E 07/ 01/2004.
0080 04 00 00 03 03 10 01 01 12 01 01 0c 02 00 01 ........ .......

-------------

I have reversed the protocol based on this and similar experiments, and my application works Ok. If you need the protocol, please pound on Digi for it. If they don't help you, and you don't have any luck reversing it, contact me and we can work something out.

Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.

Three Faces

2004-10-02T19:20:00.000-07:00

About now, I'm feeling good. My core logic is working, I'm updating code via FTP, and there's still a week left to ship time.

Wrong.

Til now, I have been working exclusively with the JTAG module that came with the Development Kit. The first time I tried loading code into a non-JTAG module, I found out two things:

1. The hardware had changed, there were now two versions of the ConnectMe in circulation and both were different from the one on my development board. More about this detail below.

2. The standard ConnectMe firmware has no FTP service. You are supposed to load new code into those devices via a web page. I could not make that work, and had to get a special command line tool from Digi. This wrinkle is explored in another post.

Hardware Changes

I am still confused about the evolution of this situation. Here's what I think I know. Before summer 2004, all ConnectMe modules were alike. The NetOS development kit through rev. D works with this hardware and this hardware alone. Call this the Old platform.

Sometime in the summer of 2004, Digi seems to have done a few things:

1. Updated the chipset's physical layer (PHY) and selected a different Flash chip, creating a new hardware platform.

2. Defined new conventions for usage of the Flash segments, as in which are locked, etc. For example, in the new scheme, the bootloader Flash is no longer locked (some say). NetOS development kit rev. E works exclusively with this new platform. You cannot create apps for the Old platform with the new development kit.

3. Defined a new part number for a totally blank ConnectMe using the new hardware and new development kit: DC-ME-01T-C where the C stands for Customizable.

4. Defined another new part number for a ConnectMe module containing a port of their original standard firmware: DC-ME-01T-S where the S stands for Standard as in Standard Plug-and-Play firmware.

BUT

5. DC-ME-01T-S uses the OLD convention for flash segment usage, and has "some segments" locked (I think that means the Boot Loader flash, but at least one person has told me that's unlocked even in the S module). The upshot is that you CANNOT create apps for the S module using the standard development kit, and you CANNOT make the S module look like a C module by wiping it clean.

6. Digi then released a development kit supplement called the Legacy Support Kit (LSK), which you could patch over your rev-E-or-better development kit and gain the ability to write apps for the S module. Despite the name Legacy, it is really for S modules and not for the Old modules as defined above.

This is all bad, but can be handled if you know it. For some reason, though, Digi seemed to be doing everything possible to keep me from finding out. I had to hit a roadblock (can't load code), try to get past it (am I doing something wrong), exhaust all possibilities (cripes it's 2 AM), send a message explaining myself (%!$#@), negotiate with them that I have already exhausted all possibilities, and then, finally, get an answer that let me progress to the next problem. I am not kidding, this went on for days. I actually had to diff the BSP source between LSK and non-LSK development kits to get to the bottom of it. When I presented my observations to tech support for verification, they said, yeah, that's what we told you last week, what's the big deal?

I ended up with three development trees on my disk:
Rev D for the Old modules
Rev E for the C modules
Rev E plus LSK for the S modules (not the Old ones despite the fact that the L in LSK stands for Legacy)

=============================

Whew - blew off a little steam there. Let me say once again that the Digi tech support folks are very professional and always helped me as much as they could - once I asked the right question. We just didn't seem to be approaching things from the same direction.

Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.

How to Build an Application

2004-09-27T18:43:00.000-07:00

Digi's implicit assumption is that you will go through the example programs under netos60_gnu/src/examples, find one that approximates your needs, and cut&paste the appropriate code into your own app. If you have any questions, you can always read the source, post to support forums or ask tech support. There is help - quite a big help file - but it is a typical reference document. That is to say, if you already know the answer, you can learn the details, but if you don't even know the question yet, you are SOL.

In addition to my core logic, my application needed telnet code (from example project natelserl), ftp code (from example project naftpapp) and raw socket access (from example project nafsockapp).

There is no facility in the standard libraries to reload code. You must include some method of updating code in your application. I use ftp, but tftp and http are both possibilities. If you ever load code with a dysfunctional update method into a ConnectMe, you have just made that ConnectMe into an OTP device.

War Story: After putting all the elements together, the ftp service didn't work. At this point, I really wasn't clear on the memory map so it was tough to know how things were failing. But they were failing. After (only) one sleepless night, I found that the ftp service needs nearly exclusive CPU access. After putting in handshake logic to idle the other threads when FTP was active, the application started working like a champ.

Hint: The FTP service has a nasty quirk. Unless your code ends on a segment boundary, there will always be some bytes left in buffer when the ftp client says "download complete." the ftp library will not write those dangling bytes to Flash until the ftp client disconnects ("bye"). So if you do what comes naturally and cycle power when the PC says "download complete" you will have a ConnectMe with a corrupt Flash image. When updating code via FTP, ALWAYS type "bye" and wait at least 30 seconds before removing power.

Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.

How ConnectMe Boots

2004-09-22T18:31:00.000-07:00

When a ConnectMe boots up, it first executes the Boot Loader. I have described that piece of code in another entry. When the Boot Loader executes your application, here's what happens:

The first code that executes is netos60_gnu/src/bsp/arm7init/INIT.s, which is part of libbsp.a (see "How Stuff is Arranged in Flash" 21Sep04). Branching from there, the BSP sets up the board and all the standard libraries. It finally calls your application's applicationStart() function from netos60_gnu/src/bsp/common/bsproot.c. Your app then sets up its own threads. After applicationStart() returns, execution passes to an idle task, and the ConnectMe is basically dead except for your application's threads.

Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.

Embedded Development vs. Linux

2004-09-22T17:23:00.000-07:00

Since starting my own consulting operation, I've been trying to do everything in Linux. KDE and Star Office make it possible to work in Linux at the office and document level (my desktop PC has 512 MB RAM and runs at 1GHz), but embedded tools are distressingly Windows-centric. I can't even inspect the files on the NetOS development kit CD using Linux because they are packaged as a self-extracting Windows executable. The exec won't open with wine because it is bigger than my system RAM (haven't tried increasing swap space).

I solved that by running the tools on my laptop (486, 64MB, Win2kPro). I loaded the development kit CD onto the laptop, and set up FTP and Telnet servers on the laptop. I used FileZilla for ftp and CygWin for telnet. Here's the command to start a telnet server on a cygWin equipped Windows box:

/sbin/inetd --install-as-service

So then I fixed up the Makefile on my Linux desktop system to ftp changed files to the Windows laptop. With a telnet session still active in another window, I could compile, load and debug from the laptop without losing the context of my desktop, with all the editors, data sheets and explanatory emails I could cram onto the screen. It really was a nice setup, and I'd recommend it to anyone.

Another advantage was I could take my laptop out to the field, tweak the code, and synch with the desktop on returning home.

Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.

How Stuff Is Arranged In Flash

2004-09-21T17:42:00.000-07:00

It took a while to figure this out. As far as I know this is not documented by Digi. I kinda think their tech support guys think it's obvious, but like I say, it took me a while to figure it out. While I was able to write my source without this knowledge, I could not understand the instructions for loading code into a non-JTAG target until this picture formed in my head.

=============================================

Memory Top
NonVolatile Memory
Flash File System (if compiled into application)
User Application (includes BSP)
-----
Boot Loader
Memory Bottom

Maybe someday I'll draw a real picture. For now, the outline above will do.

In the original ConnectMe, the Boot Loader was not user accessible. It is, however, built by the Development Kit (DK) along with the Board Support Package (BSP). In the latest DK, the boot loader image is linked as:

netos60_gnu/src/bsp/bootloader/romImage/rom.bin

In the original ConnectMe, everything above the dashed line is changeable, but everything below the dashed line is locked. So, you cannot change the boot loader (or can you...). Changing the boot loader would be convenient because it kinda sucks. When the system boots, the boot loader does a sum check of the code in application space. If good, the boot loader jumps to that code. If bad, the boot loader attempts DHCP; if that works, then it tries to bootp a new image from the DHCP server. I have not verified this part experimentally, but I have read that the bootp will only be attempted from the successful dhcp server. There is no way to escape to the boot loader on reset, or from the application; therefore, if you load code into the ConnectMe that satisfies the boot loader's sumcheck, but makes the thing continually reset, you have just wasted a ConnectMe.

The BSP source ends up as:

netos60_gnu/lib/32b/libbsp.a

and is linked into the Boot Loader as well as into your application. That took a while for me to verify - the BSP is linked into my app, as opposed to residing in system Flash like some kind of BIOS. Again, when I verified this observation with Digi Tech Support, they just said, yeah, how else would it be done?

Your application is compiled to image.elf (JTAG/gdb image) and image.bin (Flash image).

If your application requires a Flash File System, you will need to compile and link it into your app. I have not worked with this yet.

=============================================

Once I put together the information above, I was able to understand the procedures for updating firmware at the end of the Programmers' Guide:

Rebuild BSP, bootloader and application
Use JTAG and gdb to run an FTP server in RAM
Use the RAM based ftp server to load the bootloader with reserved filename rom.bin
Use the RAM based ftp server to load the application with reserved filename image.bin

Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.

Command Line GDB

2004-09-21T17:00:00.000-07:00

The NetOS development kit comes with a Tcl/Tk GUI version of GNU Debugger (gdb). I could not figure out how to drive it, and ended up using command line gdb. While I'd toyed with gdb in the past, mainly doing post mortems on core dumps, this was the first project on which I'd used it seriously. I wish I'd started long ago. This program is phenomenal.

You can set a breakpoint, then program a bunch of stuff to happen when the breakpoint fires. The last command in that sequence can be a "continue", so you can do printf debugging without changing the executable!

These are my favorite gdb commands:

p print p structure.element
b break b file:line
c continue c
^c break execution
clear clear break clear file:line

b file:line gives you a breakpoint number e.g., 1
To set the command sequence for break 1:
commands 1
p structure.element
c
end

this sequence prints the contents of structure.element and continues execution.

Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.

ConnectMe Dev Kit

2004-09-20T09:27:00.000-07:00

Digi provides a JTAG development kit (DK) for around $1500 US. The kit includes a development board, a JTAG ConnectMe module, a JTAG interface module, a CD with ThreadX, NetOS and MicroCross/GNU development tools, lots of cables, all the right power supplies, just everything you need to write ConnectMe applications. Except intelligence. You have to provide that. That fact was my first problem.

The DK came with a printed Programmer's Guide that told you how to hook up the wires, but not why. After reading that manual, and the Hardware Reference, it was not clear to me how the JTAG and the two serial ports were supposed to interact with the processor. Nor was it clear to me where the second serial port was coming from - the non-JTAG ConnectMe has only one.

As it turned out:

1. The ConnectMe module has a JTAG variant that is intended for use with this kit. The JTAG signals come out of the metal case on a little wing of circuit board material. So do the second serial port signals. You lose the second serial port when you go to the standard module.

2. The Programmer's Guide tells you how to line up the serial ports as stdin/stdout. It mentions the second serial port, but neglects to tell you that, in order to enable the second serial port, you have to change a Board Support Package (BSP) header file and recompile the BSP. I have the details somewhere, but they will probably change over time. Just be aware that it's a problem and ask Digi tech support before wasting time on it.

3. DO NOT use code that has the second serial port enabled on a non-JTAG ConnectMe (i.e. no second serial port). The BSP will hang while initializing the nonexistent port, and your ConnectMe will be TRASH (more on that later). I decided not to use the second serial port, since I hate having code that's different between the emulator and the target.

4. The JTAG interface takes over the ARM7 (NS7520) processor via debugging logic embedded in the ARM. When you load code through JTAG, you are writing the code to the processor's RAM. When you execute your code, you are forcing the processor to jump directly to your RAM based code. Once the JTAG pod takes over, no FLASH-based code is executed. That includes the boot loader as well as application code. The JTAG does not directly erase Flash, though you can load RAM based code that does so, e.g., sample project naftpapp.

5. The serial connections are not used to control the debug sessions. They come into play only when your RAM based application code is executing. The language in the Programmer's Guide implies otherwise. It makes more sense my way, but I was not sure what the truth was until I did some experiments.

6. The second serial connection is intended as a debug console for your debug session. You can line it up as stdin/stdout if you want, then do printf debugging as long as you're using the JTAG module. In fact, you can load your app onto the JTAG module's FLASH using naftpapp running in RAM, then reboot, and do printf debugging without the JTAG pod. If you want to.

Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.

Second Verse, Same as the First

2004-09-15T08:47:00.000-07:00

My second brush with the ConnectMe is going to take a while to relate. The month I put on this project was one of the most intense software development experiences of my career. Like my first ConnectMe project, it started out easy, but ended up as a crisis. this time, though, the crisis was partly my fault.

In early September, my former employer approached me about consulting on a new ConnectMe project. One customer needed some special processing done on the serial command stream, and neither side had time or compute capacity to make the changes in the time available - 6 weeks. I accepted the project, but my wife had just been in a car accident, and I was not able to focus on the project until mid September - T minus 4 weeks.

The project should have been easy. I expected it to be easy. I wrote a command line program that implemented and tested the core logic in about a day. I think it was a Sunday. Then I tried to port that program to the ConnectMe. Four weeks later, I was still struggling with the ConnectMe platform. I lost so much time struggling with the ConnectMe platform that I ended up traveling to the customer site to finish the software there, on their ship day.

Lest you think I'm some kind of liberal whiner, be aware that over the past five years I have delivered the software for an entire product line, including 3 different processors as well as Xilinx programmable logic. I designed the communication protocols involved here. The ConnectMe environment kicked my ass. For a while. I finally figured it out, and still believe it was worth the struggle. Even if you pay full price - U$D 40 - you can't beat what this little guy can do.

Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.

ConnectMe Life Support Board

2004-03-27T22:10:00.000-08:00

An open-source schematic for a minimal ConnectMe life support board is posted on my website:

http://www.gluelogix.com/ConnectWiMeRS232.shtml

Scroll to the bottom.

Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.

First Encounter

2004-03-01T17:00:00.000-08:00

My First Encounter with the Digi ConnectMe came in Feb2004 when my employer found a customer who refused to consider our equipment unless it had an Ethernet jack. Bit of background: the last five years of my life have been spent with an RF startup. We got the baseband interfaces defined and implemented early on, giving our early customers something stable to work with. Then we concentrated on the RF for a few years. The problem was, the baseband world changed on us. In 1999, "internet devices" were hokey dialup things like the ATM at your local squishy-mart. At that time, it was still reasonable to field a device with an RS232 interface. Even in multidrop networks, it was easier at that time to get electricians to pull RS485 than Ethernet. No more. Now that 10BaseT and 100BaseT and God-knows-whats-next has taken over, you can't compete unless you have Ethernet too.

So we got Ethernet. It took around two weeks.

We had already noticed the ConnectMe, and were waiting for an excuse to use it in something (there was one other small Ethernet-to-serial filter device available at the time, but it was based on the 80186 and had a fraction of the ConnectMe's memory).

When the customer delivered their ultimatum, there was actually plenty of time to do a deliberate development. But by the time management took the ultimatum seriously (i.e. it became a crisis) we were around 3 weeks away from a make-or-break demo. As it turned out, we were able to put together a couple of prototypes with days to spare.

Since there was no longer time to respin our main circuit card with the ConnectMe on board, I designed a very simple and small circuit card that could be wedged into an underused corner of the enclosure. All it really needed was an LM-series voltage converter, the ConnectMe itself, and a place to land jumper wires. Our tech cut the square hole in the case and ran jumpers from the ConnectMe to the main board. Plug in, turn on, and fugedaboudit.

But even at that there were some problems.

Our first ConnectMe that was actually soldered into a circuit communicated very intermittently. It sometimes took minutes to boot up, sometimes never booted up at all. Its brother, on the JTAG development board, never had a bit of trouble.

The problem turned out to be my reset circuit. I had put a couple of bells on the interface board, like 3.3 to 5 volt translation and a nice RC reset circuit. Turned out, the ConnectMe has an internal RC network on the Reset pin. They expected people to implement Reset with a simple switch to ground, no debounce, etc., but as far as I can tell, that fact is undocumented in the Hardware Reference. In any case, when we removed my RC network, we fixed the problem. The Ethernet prototypes shipped and the customer checked off the Ethernet square on their acceptance test.

Two weeks calendar time, probably a man-month spread between me, another software guy and two techs, plus the cost of creating the interface board. One guy on the team said he told a friend what we'd pulled off. The friend, probably a big-company expert on these matters, said "That's impossible." Sorry.

Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.