Digi ConnectMe Notes

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.

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 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 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.

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.

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.

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.

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.

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.