New bootloader image won't correctly recover using DHCP/TFTP

Embedded Devices NET+OS
21

So you’re saying that the modules work for a while, then “lock up” permanently? In other words a reboot doesn’t fix it? If that’s the case, my first thought would be that some sort of non-volitile setting or state is being set somewhere that is causing the module to hang in some call. I might be stating the obvious here, but I just wanted to be clear.

Do you have a JTAG unit and debugger to test on? Is the situation repeatable enough that you could use the IDE to step through on startup, after the situation occurs, and find out where it hangs?

Another thought is that if your application runs long enough, can you use it to immediately update your bootloader to one that works (via FTP)? That way you could recover when it starts hanging again?

But now I’m thinking that if it’s some nonvolitile setting that’s causing it, then replacing the firmware image with an identical one won’t fix the problem.

22

Yes, once it has locked up, it never returns, but I don’t know what triggers it. Anecdotally, I’d say you are right, something that updates the nonvolatile storage causes it, as most reports are that it happens when network settings are changed, similar to the situation that occurs when someone sets an incorrect static IP, but not the same, because in that case something like netosprog can get it back, and in my case you never get a TCP stack up for netosprog to talk to. I can verify no TCP stack comes up via ethereal/wireshark. Not a peep from anything with a Digi MAC.

23

In case anyone looks, I see what causes my modules to lock up, most of the time, anyway. The CTS line (pin 11) on my board was initialized to high at power up. Apparently, older modules (with M or R under the end of the bar code) didn’t mind this, but the latest modules (with T under the end of the bar code) will not come up with CTS high. I changed my software to initialize that line low, and the modules usually come up. Every once and a while, it won’t, and I have to cycle power, and usually it will come up after that. It is annoying, but at least I haven’t bricked 30 or so units.

24

Which barcode, the one on the side, or the one on the top?

I have a G under the end of my barcode.

25

The one on the side. The top one is the MAC address.

The three I have on hand look like this:

Vertical on left:
CoO: THA
0701

|||||||||||||||||||||||||||
PN: (1P) 50000878-03 R
| -C 95010720E

Vertical on left:
CoO: THA
0625

|||||||||||||||||||||||||||
PN: (1P) 50000878-03 M
| -C 95010720E

Vertical on left:
CoO: THA
0745

|||||||||||||||||||||||||||
PN: (1P) 50000878-03 T
| -C 95010720E

Forgive the formatting, this board compacts the spaces for some reason.

My guess is that the number vertical stuff on the left is “CoO = Country of Origin” and “THA = Thailand” and the number is the year and week of manufacture.

Jeff.

26

I had to RMA my unit. Assuming your unit is ignoring your active TFTP server (like mine was), then you probably will have to as well.

27

Hi,

There were some minor glitches in the 7.3 bootloader. I have provided a link to a site that has all available patches for 7.3. I would recommend loading (at the minimum) the following patches:

  1. BSP Updates
  2. FTP Updates

7.3 Patches:
http://www.digi.com/support/productdetl.jsp?pid=2466&osvid=159&tp=6&s=53

After loading the patches, open the ESP and rebuild your project.

If you need to recover your module and are having difficulty, try the Xmodem recovery method I have outlined below for recovering the module.

The recovery method described here are assuming the module is plugged into a Digi development board. When we reference certain pins to be jumped, we are referring to specific pin headers on the development board.

We currently have two styles of development boards. On the older dev board, we are referring to the “MFG” or P5 pin header located next to where the module plugs in. On the new dev boards, the pin header is designated as P9.

Shorting the “/init” pin (pin 20) and the “MFGI” pin (pin 18) to ground, power up the module, and watch for the message “Starting Recovery…” on the serial port at 9600/8/n/1 no flow. Once you see the "C"s creeping across the screen then the module is now ready to receive the new image via the serial connection.

Now, open an Xmodem connection via the serial port to the Digi module (9600 baud, 8 data bits, no parity, 1 stop bit, no flow control). Hyperterminal in Windows will have this capability. The module should show the progress and the image is transferred via serial to it.

Once the image is finished being transferred, the module will write it to it’s flash chip. This process may take a minute or two. After this is finished the module should reboot and execute the uploaded image.

NEW style development board:
For doing a recovery using the “NEW” development board, two sets of pins need to be jumpered.

  1. Turn off power switch on development board.
  2. On the twenty pin header labeled “P3” (located to the left of the ME module, next to the two pushbuttons), jumper pins #16 and #20.
  3. On the 4 pin header labeled “P9” (located close to the power connector), jumper pins #3 and #4.
  4. Turn on power switch.
  5. Watch the output of the serial port, continue remainder of recovery procedure.

Regards…
Scott

28

This didn’t work for me. My unit went instantly to the error after power on, I had no chance to use TFTP or xmodem. I think that there was a failure with that unit only, introduced with a power surge or during transmission of the bootloader as the same bootloader worked perfectly fine on other units I had.

29

Hello,
please do you some advice for recovery Connect EM module?
I did some tests with SW1 button on module, but no success. But there is 4-pin connector on module, labeled P3, but it’s not documented anywhere … Maybe it’s the key, but I don’t know.

thank you, regards Michal

30

My module is soldered into a product board rather than being able to plug it into the dev board but shorting pins 18 & 20 to GND made no difference to my case.

I still get:

Starting Recovery
TFTP

Abort Exception

I too have used the serial recovery method in the past (albeit with a unit plugged in to the dev board)