Wednesday, October 06, 2004
The End...?
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.
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
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 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
dgdcprog /set /firmware=image.bin /mac=(MAC from previous reply)
Larry Martin
www.GlueLogix.com
Copyright (c) 2004 Larry Martin. All Rights reserved.
Tuesday, October 05, 2004
Discovery
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.
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.
Saturday, October 02, 2004
Three Faces
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.
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.
