How to Reset Digit Connect ME to factory Defaults

Hello!
I’m sorry, but I’m just beginner in Digi world, so… sorry, if something wrong…

So yesterday I was connect to Digi Connect ME, through network cable and put through ftp one default GPIO example, before that this device was real new, and now I can’t reach this device, not ping, not through COM port (hyper terminal), so what to do? How can I restore the default factory settings? The reset button gives no effect, and not even jumper on P12. So please help me!

Cannot reach ME !

Which version of the ME? Old, -S or -C? JTAG or no JTAG?

  1. If you have a -C module, you need to return it to Digi.
  2. If you have a JTAG, just reprogram it.
  3. If you have a -S or an Old style, you can erase it and reprogram it via TFTP in diagnostic mode.

-Erik

Hi Cameron,

I tried your “customBootLoader” to launch TFTP to reload an application starting with the /INIT pin and it seems to work. However the image.bin (I tried with “NAftpapp”) is succesfully downloaded but the flash write fails always. More strange, “NAftpapp” starts after that and seems to work.
Is it something I need to know before doing more tests? Have your sources not been completely tested?
Thanks,

Paul

Hi,
I work with C (it’s new one? I think!)
and with no JTAG! So I need just return it to Digi???

  • EGRO

The -C modules, once they are programmed, cannot be externally reprogrammed. They can only be reprogrammed from your code or from a JTAG. If your code is not working and you don’t have a JTAG, you are out of luck.

The -S module is the new version of the original ME. It has a bootstrap that allows for external modification by toggling a pin (Pin19).

The whole idea of the -C module was supposed to be for uCLinux images that were already compiled and stable. The -S modules were supposed to be for people doing embedded programming. For some reason Digi decided to distribute the -C modules to everyone. It has caused a lot of problems for Digi and lost them a lot of customers.

-Erik

Speaking of uClinux - how to get it running on a -C module?

Hi,

I have got the same problem with Digi connect EM ( -C module ): since a bad ftp operation the module refuse to reboot correctly. I think the image of the application is incorrect .
In same time, I comment out the NAFastMemoryTest to reduce the booting time, maybe it causes problems when the Digi restart.
I need to know how can I process to reprogramme it or restore defaults parameters (or application?).

Erik,

Has it partially correct.

Originally, all Connect ME modules were of a -S type, with Digi’s boot loader and post image stored in flash. Late last year we released a next generation version of the ME, which included a new Ethernet PHY and ROHS lead-free compliance. It was with the release of this nex-gen module that a decision was made to split the ME family into the -S (standard) and -C (custom) branches.

The -S modules are primarily intended for use with our Integration kit and Digi’s plug-and-play firmware. IT is also possible, by way of our Legacy Support Kit (LSK) add-in, to use these modules with our NET+Works Development Kit.

The -C modules are intended for use with our NET+Works Development Kit as well as persons wanting to work with other operating systems, ucLinux, VXWorks, etc.

The difference between the -S and -C modules are strictly related to the contents and condition of the flash.

The -S module has its first 128KB of flash protected (this is where the boot loader is stored. This module also requires teh use of our post image (128KB). The remainder of the flash is used for firmware image storage, flash file system, NVRAM and a reserved portion of flash, used by our Boot/Post. There is limited flexibilty in how the flash can be utilized. You are provided no control over the boot and post loader code.

The -C module’s flash is left completely unprotected. The boot loader is a standard image, the source code for which is provided in the development kit. The remainder of the firmware is usagble in a fairly flexible manner.

As for recovery methods the default application (firmware) image implements a FTP server which allows you the abilty to upload a replacement boot loader and/or application image and have it programmed into flash. Other methods of software upload are certainly possible, teh FTP server is the default method which is provided with the development kit.

During the boot process, if the stored application image is found to be corrupted or missing there will be an attempt to enable the Ethernet interface and acquire IP configuration via DHCP. As part of this DHCP offer the boot loader will look for options 66 (Boot Server Host Name)and 67 (BootFile Name). With this information the boot loader will attempt to retrieve, verify, write to flash and execute the specified application image.

With the development kit, since the source code is provided, it is certainly possible to implement additional boot loader features.

Examples:

  1. Implement mechanism by which shorting the /INIT pin during boot will cause the boot loader to output an interactive interface by which one could forece the downloading of a replacement application image.
  2. Modify both the boot loader and BSP to support the storage to two application image in flash, one being a recovery image, using the naftpapp application, the other being the target application. Decision as to when one or the other image is executed could be made automatically via the boot loader, via a user interface or by way of one or more GPIO pins.

I have working implementations of both of the above examples available if anyone is interested. Please send in a request for the source by way of our online support request form at http://www.digi.com/support/eservice/eservicelogin.jsp.

Also, as Erik has stated, without the availability of a JTAG interface the only way to get a new image into flash is by having some mechanism already implemented and available from within flash, i.e. the boot loader of application image needs to have the ability).

Cameron