Digi Connect ME4 9210 reset from static IP back to DHCP

Question

We have a setup with around 90 Digi Connect ME4 9210 modules, connected to a single server from multiple switches. All modules are set with fixed IP addresses so our application can connect to each module individually.

The setup has been running without any problems. But suddenly a lot of modules (10+) have been reset to factory settings without anyone modifying them. This has happened to different modules, at different points of time. The modules were set back to DHCP instead of fixed IP, and their IP addresses were all set to 0.0.0.0. They didn't get a new IP address. Our application could then not connect to these modules. Their old IP addresses were not taken by any other devices, as this is a closed network only used by these modules and the server.

Our application does not invoke any form of factory reset command to the devices.

We have manually modified the devices back to fixed IP settings, but after a while they are reset.

There are multiple switches connecting the modules placed around several buildings. This happens to modules on several switches, and is not related to a faulty switch or faulty LAN cables.

The fixed IP addresses have been set to a range outside the router's DHCP range. We have restarted the router, but these resets still happen.

Are there any other way the modules could behave like this than doing a manual factory reset?

Are there any settings for the router or switches we should be aware of which might cause these resets?

Answer 1

NVRAM is protected by CRC, which means that upon system boot Netos calculates the CRC and compares it with one previously stored in FLASH calculated during most recent write.
The NVRAM would reset to defaults as you’ve described in 2 cases:
-user requested Reset of NVRAM in serial dialog or through iDigi (or software purposely or accidently calls “reset NVRAM” customizeUseDefaultParams(nvParamsPtr)
-during boot NVRAM CRC check fails and systems decides it needs to reset NVRAM to default values.

This can be caused by accidental FLASH write to NVRAM sector (due to memory leak in code or file-system growing too much for example). Another reason could be a bad FLASH, where read of some blocks is inconsistent. But the most common reason for this to happen is when power-cycle or external reset was triggered during the legitimate system write to NVRAM. If such even comes when system already wrote the new variable to NVRAM but before new calculated CRC was updated there, the CRC check will fail after reboot and system will reset the NVRAM structure to default as designed.

Does your system has to do frequent updates to NVRAM? Can they be eliminated? Was the size of the NVRAM sector increased? Do you use FLASH filesystem? You can consider implementing backup NVRAM sector that will be copied to the main one instead of reset to defaults.

Answer 2

For Connect (Wi-) ME (9210) with plug and play firmware check the Digi Connect Family Users Guide:
http://ftp1.digi.com/support/documentation/90000565_P1.pdf
pages 155/156/157

If you have connected pin 20 /init in your circuit, the device will reset back to factory default if pin 20 is connected to ground (similar like pressing reset button) while you power on the device.

Avoid driving back power through the Connect ME (9210) signal lines before it has got valid power. E.g. if you have connect its I/O or UART line to an external IC which is powered earlier than the Connect ME, this can cause mal function or the module being locked up/not booting at all.

Buffers between external IC and signal line being enabled only when stable power is supplied can help to fix this. see hardware reference manual HRM: http://ftp1.digi.com/support/documentation/90001247_C.pdf or newer version from support website:
http://www.digi.com/support/productdetail?pid=3510&type=documentation