This document describes how to recover a Digi Connect ME (9210), EM, & SP JTAG'less C module (hereafter defined as a module) with a user defined image.
These modules however need to be the ''C'' or Custom variant. They also need to be C modules without a JTAG interface. C modules with JTAG interfaces should use the NAFTPAPP example application to load the intended image instead of using this method. This procedure will not work on ''S'' or standard modules, nor on U-Boot/Linux modules. As a result, it will not work with Integration Kits or with Development Kits running with S modules.
This procedure will only work with XModem on the wireless versions of the modules (Wi-ME, Wi-ME 9210, Wi-EM, Wi-SP).
The recovery method works by either download a new image to the module via a TFTP/DHCP server or by a simple serial transfer using the Xmodem protocol. Both are discussed below.
If the module still has it's default factory boot loader, or a boot loader image that contains a recovery method, it may be possible to force a recovery by shorting the /INIT and MFGI pins to ground (GND). Depending on which version of Digi development board you use, below table shows where to find those signals on the Digi development board:
|signal name||ME module pin||30006002-04/-05/-06||30006002-02||30006002-01|
|/INIT||20||Signal Rail P3 pin 20||P12 pin 3||P12 pin 3|
|GND||16||P5 pin 3, or MFG P9 pin 4 or GND loop next to RESET button||P12 pin 2||P12 pin 2|
|GND||16||MFG P9 pin 4||MFG P5 pin 4||MFG P5 pin 4|
|MFGI||18||MFG P9 pin 3||MFG P5 pin 3||MFG P5 pin 1|
The Digi Connect C JTAG modules are designed with development purposes in mind. The developer is expected to write their image (a.k.a. EOS, firmware, & application) with the JTAG C modules and then test it. When they have tested their modules to their satisfaction they will then want to deploy their image out to their JTAG'less C modules for manufactoring purposes. For whatever reason, sometimes images can be written wrong, become corrupted etc. This document gives the users a chance to recover their JTAG'less C modules.
This document is not a guaranteed fix however. It's going to depend on why the module is not booting. That will determine if this procedure can restore the module or not. Here is why.
When the boot loader on the module starts up it checks the image header (first 65 bytes) and does a Cycle Redundancy Check (CRC) on the image as a whole. If CRC check fails then the boot loader will attempt to find a DHCP server in order to recover an image. Now, if the image doesn't work BUT has a valid image header AND passes its CRC check, then you can force the boot loader into recovery by means of above pin shortcut.
If none of these works, the module will need to be RMA'd.
It is assumed that the reader has a C module with a development board. The reader is expected to be familiar with networking and computer related concepts. They are also expected to have a basic understanding about the Digi Connect module (install, setup, & configure).
1. TFTP/DHCP RECOVERY METHOD
DHCP server :- This will need to have the ability to set options 66 (name of TFTP server) and 67 (file to download).
Digi Connect module (C without JTAG) - ME, WiME, EM, WiEM, & SP
new image for module
Note: In the below procedure we are using an application which has both TFTP & DHCP servers.
Setup a DHCP server & TFTP Server
This must have the ability to define DHCP options 66 (IP address TFTP server) and 67 (file to download).
It is advised to connect Digi module and PC directly . ie: Remove from existing network.
Advantages:- Troubleshooting is easy
It will not disturb your existing DHCP server @workplace
setup servers with image
Download from 32bit http://www.jounin.net/download/Tftpd32_SE-4.00-setup.exe or 64-bit http://www.jounin.net/download/Tftpd64-4.00-setup.exe executables.
Install one of them accordingly. After installation copy application image (image.bin) to
Note: nn stands for 32 or 64.
Disconnect PC from existing network or chose a standalone machine.
Disable Windows Firewall
If you have any Virtual Machine turned ON please turn it OFF.
Assign a static IP to ethernet or wireless interface.
Connect PC and Module using a cross cable. (if non-wireless varaints)
And start installed TFTP & DHCP server.
Configure both servers as shown in the following screenshots.
Enable Both servers
DHCP Server Config
TFTP Server Config
Once configured, restart TFTPnn.exe and turn on the module.
Device will start and show TFTP recovery message in serial terminal, followed by image download.
ScreenShot : IP assign to Digi Module
Screenshot : File Transfer
Reboot device and it should be fine then.
After a short period of time after the download, the module should reboot itself. After this the image should be recovered.
2. SERIAL (XMODEM) RECOVERY
-Digi Development Kit on a PC or laptop
-Digi Connect Module
-crossover serial cable with DB-9F ends
-Digi bootloader on the module
-Digi image to load (usually image.bin)
It's assumed that the module already has a corrupted image and it's bootloader is intact.
Connect a serial cable to the modules first serial port. Open a terminal program with the following settings (9600 baud, 8 data bits, no parity, 1 stop bit, no flow control).
Power up the module. Once you see the "C"s creeping across the screen then the unit is now ready to receive the new image via the serial connection.
Next, open an Xmodem connection via the serial port to the digi module. Hyperterminal in Windows 2000/XP will have this capability. In hyperterminal, go to 'Transfer' -> 'send file'. Then, from the send file window, select 'Xmodem' for the protocol. Now, select the appropriate image file (image.bin) and press the 'send' button.
The module should show the progress and the image (generated in the 32b directory of the compiled application) is transferred serial to it. Once the image is finished being transferred the module will write it to its flash chip. This process may take a minute or two. After this is finished the module should reboot and since you have still the pins short to GND, you will again see "Starting TFTP recovery..." message. Power off the module, remove the /INIT and MFGI to GND connections and repower the module in order to see the recovered image.bin booting.