New Connect ME 9210 -C modules won't run our image.bin application!

Embedded Devices NET+OS
, , , ,
1

What’s broken with the latest Connect ME 9210 -C modules (DC-ME-Y402-C
)? I used the default factory ftp server application to load our image.bin. The file was accepted and appears to have been programmed into flash. But the module appears to hang instead of running our app. When I power cycle the programmed device I see the same LED pattern as a working device, but no ethernet or serial comm (at least at our baud rate–I should scope the line just to be sure).

I tried grounding pins 18 and 20 at boot; that put the module into the bootp/tftp recovery mode. This would suggest that our image.bin was accepted and that the Digi bootloader is jumping to our app, which then hangs. Right?

We just received the order of 150 that was on backorder with Mouser for 14 months! In our excitement to finally have some parts, we expedited them to our CM and had them solder the modules into our product, drove up late Friday to pick 'em up, and then learned Saturday morning that the modules won’t run our application! We’ve used probably 1k of these devices with this image.bin over the last 12 years and I’ve never seen anything like this before.

I used our automated script to load the first image. When it failed I thought “hmm, weird”. Tried a second with the same result–that’s really weird. I turned off the script and drove ftp by hand for third module, and when it failed I knew we had a big problem.

Here’s a cut-n-paste of my FTP session:

ftp 192.168.0.142
Connected to 192.168.0.142.
220 NET+OS 7.6.1.8 FTP server ready.
Name (192.168.0.142:pi): root
331 User root OK, send password.
Password:
230 Password OK.
Remote system type is NET+ARM.
ftp> bin
200 Type set to I.
ftp> put image.bin
local: image.bin remote: image.bin
200 PORT command Ok.
150 About to open data connection.
226 Transfer complete
756248 bytes sent in 0.40 secs (1.7835 MB/s)
ftp> quit
221 Goodbye.

If I FTP into the new module running the factory application, I see this:

Welcome NET+OS 7.6.1.8 Command Line Interface

#> version
NET+OS Version 7.6.1.8
Copyright (c) 1997-2011, 2013 Digi International, Inc.
PLATFORM: connectme9210 (Built: Mar 02 2021 10:00:46)
APPLICATION: Ram-based FTP Server Application (PN: 82001946) (Built Mar 2 2021 10:03:49)
on LOG-CMS-LOAN02
with GCC 4.2 (4.2.0 Microcross GNU X-Tools™)

flash info
0: 8K 1: 8K 2: 8K 3: 8K
4: 8K 5: 8K 6: 8K 7: 8K
8: 64K 9: 64K 10: 64K 11: 64K
12: 64K 13: 64K 14: 64K 15: 64K
16: 64K 17: 64K 18: 64K 19: 64K
20: 64K 21: 64K 22: 64K 23: 64K
24: 64K 25: 64K 26: 64K 27: 64K
28: 64K 29: 64K 30: 64K 31: 64K
32: 64K 33: 64K 34: 64K 35: 64K
36: 64K 37: 64K 38: 64K 39: 64K
40: 64K 41: 64K 42: 64K 43: 64K
44: 64K 45: 64K 46: 64K 47: 64K
48: 64K 49: 64K 50: 64K 51: 64K
52: 64K 53: 64K 54: 64K 55: 64K
56: 64K 57: 64K 58: 64K 59: 64K
60: 64K 61: 64K 62: 64K 63: 64K
64: 64K 65: 64K 66: 64K 67: 64K
68: 64K 69: 64K 70: 64K

If I reload our image.bin using the bootp/tftp recovery method, I see this:

Starting TFTP recovery…
Writing to Flash…
Resetting…

What I have: a known good image.bin file that we’ve used for 1k installations over the last 10+ years, 147 new and presumed defective 9210 modules with the factory application soldered to our product, 3 new defective 9210 modules with our application, a NET-OS 7.5 CD, dev board, old 9210 Wifi+jtag module, and a handful of known good 9210 modules with our application.

What I don’t have: an old known good 9210 with factory application to compare telnet/ftp server versions, a new defective 9210 jtag module, source for our application (we license it from another company).

Is it possible these new modules left the factory with a buggy bootloader that’s not fully init’ing the hardware, and that’s the cause of these hangs? Surely there’s not a hardware incompatibility, right?

We really need a solution that doesn’t involve spending $3k unsoldering and resoldering these modules. And of course the 9210 have been impossible to get for over a year, so it’s not like I can just order more.

thanks for any help/advice/suggestions!

2

I suggest you contact Digi Technical Support with your specific part number, MAC address and 4 digit date code.
When your custom image.bin does not boot, but you did not overwrite the boot loader rom.bin, you can recover the module (with a working image.bin) by means of the recovery procedure:
https://www.digi.com/support/knowledge-base/how-to-recover-a-digi-connect-wi-me-9210-wi-em-and

Your FTP session is just quitting at the end. If you are power cycling the module at that moment, your flash programming might not have finished and you end up with a partially programmed corrupted image.bin in flash. You always have to check the serial port output for the flash programming progress output.

Since 2018 Digi was required several times to add new flash chips to the approved vendor list on the Connect ME 9210 modules due to unavailability. Product Change Notices (PCNs) have been published to distributors about this. If your NET+OS firmware image.bin does not include the latest flash patches, this might explain why your firmware is not working.
All of the approved flash chips might be used during Digi manufacturing at any time, also the old flash chips if temporary still available. So you can’t be sure by date code which flash chip is actually soldered and your firmware needs to be prepared to support all of them!

So make sure your NET+OS ESP is based on the latest released NET+OS 7.5.2 and does include all updates via the PackageManager. Also make sure after a PackageManager update, that you create A NEW PROJECT, merge in your changes in the new project and build your image.bin in release mode. Updates are not populated in the NET+OS ESP into existing projects!!

3

Digi tech support also tells us the old firmware probably doesn’t support the flash memory device on the new modules. I’ve confirmed that the old modules that work have a M29DW323DB, but the new ones use a Macronix MX29LV320EB.

Thanks for the pointer about monitoring the serial port. I was not doing that, but I’m seeing some useful diagnostics, especially in TFTP recovery mode. I’ll probably build out a programming fixture to support this.

Our production setup script doesn’t kill power at the end of the ftp session. There’s quite a bit more to do than ftp the image.bin over…it’ll wait a few seconds for the module to burn and reboot, ping it until it’s back up, log into the new application and configure the serial port and network, then run some tests to be sure everything is ok.

In the future I think I’ll configure the Digi devices before they’re soldered into our product so that we don’t end up in this 6 figure WIP mess again.

BTW, has anyone else noticed that the TFTP recovery method doesn’t check the image length or checksum?

4

Hello,
I have a problem with new revision of DC ME 9210-C (MAC DF2618) - we have unfortunatelly updated rom.bin in production (with default FTP application) which makes Exceptions on console output.
I am able to start TFTP recovery, but it looks like that it’s not possible to update rom.bin within TFTP recovery - is that correct ? Only image.bin can be updated with TFTP ?
Is there any way how to recover ?
thank you in advance for support, best regards
Michal

Prefetch Exception
CONTEXT: INTERRUPT

Program Counter :029BA80E
Stack Pointer :0012C878
Current program status Register :200000D7
R00:FFFFFFFF R01:0012C8FC
R02:00000004 R03:029BA80F
R04:FFFFFFFF R05:00000004
R06:0000000A R07:0012C8FC
R08:00000002 R09:A0900160
R10:00130560 R11:00000000

5

yes the TFTP recovery of the boot loader is uploading image.bin only.
just check the NET+OS toolchain boot loader source code for confirmation.

6

dvorak,

I unfortunately (and mistakenly) used FTP and put my rom.bin onto a connect ME9210, DC-ME-Y402-C. After that it would not boot into the image.bin. Fortunately it was a single unit (as these are rarer than gold now), and it was plugged into a development board. I have tried to fix it using the serial recovery method but still cannot get it to boot properly.

I tried using serial recovery to reload my rom.bin and I get a similar response as you cite (Program Counter… etc). Have you found a way to recover from this? Is there a factory rom.bin available that will work? The serial recovery DOES allow me to upload image.bin, writes to flash, and resets, however it jumps back into tftp/serial recovery message after reset or power cycle.

I took another one from stock and ONLY ftp’d the image.bin and it worked fine. Needless to say I will no longer make the same mistake with rom.bin and just use the factory installed version. I would also have no problem writing this one module off as a loss, expect for their rarity; not to mention having a solution would be nice for the future and for anyone else that makes this mistake.

Leonid??

Regards,

Adam