Digi Connect ME without JTAG

Many thanks, Erik.

Hi Cameron,

Don’t you have any Digi’s official papers to send to me about this subject ?
I’m working with a Digi Connect ME Development Kit and I would prefer trying this last chance method before I start flashing new software on Digi Connect ME modules (those without JTAG extension). Could you give me some more information about the prefered tools to use on a Win2K workstation (BOOTP/DHCP server ?).

Thanks

I don’t know if the ME versions differ somehow, but the correct pin seems to be 19 (MFGRST) (at least in my version of the server). Tried that yesterday and it works, only thing that the tftp client seems to be a bit odd because i need to do n retries before it starts to download the image from server.

Pin 17 seems to be MFGO and 18 is MFGI and either of those tied to ground won’t affect anything during bootup.

Application = Firmware.

What this thread is talking about is the “Diagnostic” mode of the ConnectME. This mode has a TFTP client that will update the firmware from a remote server.

Digi is scared of this interface and will only tell you about it under duress, and I have heard that they are removing it from newer modules (although everyone I have talked to thinks that is just plain stupid of them to do). It is the only way to recover a module that has a bad program in it.

If you have a working app, it would be wise to build in a way of updating it remotely. Digi recommends a FTP server or client. I personally duplicated their bootstrap and wrote a TFTP client which works great for me (and is also secure since it is a client only).

-Erik

I have a confirmation from Digi, I put it below as it is interesting for evryone (Again, many Thanks for the Digi support team). So as you say Erik, Digi does not support this “Diag mode”, if still existing (I’ve also asked Digi support about this…).

>>>>>
I would like to note that you should be careful about loading the appropriate image into a –C module. If the image is loaded and it overwrites the flash and the image does not work, there is no way to recover the unit.
Is the Jtag’d module you have been developing with a CF/W jtag’d module? Are you using Net OS version 6.0 D (or later)? If yes to both then your image should be fine to just load into the new –C module (assuming you haven’t been using the second serial port, or if you have, that you have disabled it).
You can check which version you’re running by viewing the readme file in the netosgnu_60 directory (listed as a build) and we can verify what module you have by the part number.

You where right, Digi anwser is :

>>>>

The Diagnostic mode is not something Digi supports. It is a tool that we use during manufacturing, and we make no promises that it will be included in the future. The –C modules do not have the menu in the boot. Since the –C modules have unlocked flash, however, we do provide the basic boot loader code that we use for the –C modules (which does not have the diagnostics menu in it). With the boot code you are more than welcome to modify it or create your own code to add your own ‘back door’ for updating or recovery.

In other words, we are screwed if we load a bad program into the module. sigh I wonder who the bright executive who thought this one up is? He/she probably got a bonus. sighsigh* Obviously not an engineer.

Are we living in Dilbert’s world?

In a less exasperated veign,
Leaving auto-discovery code in the program (as is mentioned above) is NOT an option for anyone who wants any security. Doing so will prevent any product that has this code from even the lowest level of government approval.
My company uses the ConnectME in several devices that we sell to the US government (and several other governments), both military and non, and this is totally unacceptable. There needs to be a method of CLIENT-ONLY recovery. My company has already started researching alternatives to the ConnectME because of this issue.
As for creating our own code for back doors, that is a plan. We have the old ME modules for shipping the current batch of devices, and I will be working on a repaired bootstrap for when I have to deal with the new ME modules. I will probably post it when I get it done (sometime in February I think). If anyone gets some good code before that, please post it.

-Erik

As I read this thread, do I understand well that the Digi cancelled supporting the diag-mode feature and it will be unavailable in future?
Is there the bootstrap code, which couldn’t be destroyed by writing the application image?
Or I need to re-write the BSP package to create my own “back door”?
I’m a bit surprised reading that.
Can someone help me to identify the Connect ME module check, if it is “diag-mode-able”?

Viktor,
There is a bit of confusion on this issue. There are two stories coming from Digi.

Cameron says that the new ME (-C model) does NOT have a diag-mode bootstrap, and comes just with the autodiscovery code that gets overwritten.

The engineers that I talked to over at Digi said that they see the problem and there are two versions of the ME, one with the bootstrap and one without.

So far, it appears that Cameron is right. I have not heard of one of the new MEs with a bootstrap. :frowning:

Several people I know of are writing a new bootstrap for their use. I have TFTP code that I can adapt into a bootstrap, but I am busy getting the end of year stuff out the door right now.

-Erik

They sent me a new ME (-S model) by mistake.
This module had a the diag-mode bootstrap
in the same manner as the old modules!

I assume we probably could use those models
in the same way as the old ones (of course
without discovery feature on delivery and
after rebuilding your image).

I’m not sure, I haven’t tried, I sent the
ME(-S) back. (I should not have done so)
Maybe someone can confirm that.

That would be exactly the opposite of what Digi
wanted to achieve - using the Standard type for
the customer applications.

But if you all are right using the ME (-C)
model is not acceptable for me at present!

Message was edited by: NoBo

We are using the -S device, which is basically the same configuration as the original. The boot and diagnostics are still in locked flash. Unfortuanately, when we got our initial devices and SDK, there was no documentation on the “Legacy Support Kit” for these devices. I got it working after Cameron explained a couple of details. For one, the platform name for MAKE changed to “connectme_lsk”.

The information we have says they will be supporting both the -C (custom) and -S (standard) versions.