Hi! I’m using a set of two Digi Connect ME modules on a back plane to support Ethernet communication. There are two layouts of the back plane, A side and B side. A and B are almost mirror images with each other with the same net list and the only difference is that on B side, there is a 5V power plane lying under the Digi modules. But the Digi modules should be isolated from the 5V plane since none of Digi’s pins are connected to that plane. They went through and are only connected to the 3.3V. I programed Digi and load application to it. My problem is that all Digis on A side (without 5V plane) works very well, but the Digis on B side have about 50% failure rate. The two Digis on B side always has the same status, either both programed successfully or both failed. The failure is that it lost its MAC address and all returns to the same default MAC address which is 00:40:9D:43:35:97. I don’t know a way to reprogram the bad Digis and recover its MAC address. I’m wondering if anyone has any idea what was happening on the B side back plane and how I can recover MAC address of bad Digis.
I attached the pictures of both A side and B side back planes. The 5V power plane is marked by red.
We have used the digi for several years in different designs and only in a new design are we seeing this problem.
What we did to work around this problem is to have some startup code that copies the MAC address to NVRAM the first time it runs and if the MAC address ever goes back to the default on startup it gets set back to what was saved to NVRAM.
It would be great if we could figure out what causes this.
00:40:9D:43:35:97 is the default MAC address that NET+OS writes to NVRAM when NET+OS senses that NVRAM is corrupt. The most common reason for NVRAM to be corrupt would be that some or more piece(s) of information in NVRAM were updated but the checksum associated with NVRAM was not updated. When customizeReadDevBoardParams is run, the first thing it does is calculate the checksum and then compares the calculated checksum with the checksum previously written to NVRAM. If the two do not match, NET+OS assumes NVRAM is corrupt and writes a “default” version of the NVRAM data of NVRAM.
What some customers have done, as evidenced by a prior posting is write the good MAC address to somewhere, for example to the FLASH file system. Then if the module comes up with the default MAC address, your software can recover the MAC address from FLASH.
Now specifically why some of your modules lose their MAC address and others do not, some event is causing NVRAM to become corrupt.
MAC address is stored in last sector of your FLASH which is simulating NVRAM. The entire sector is protected by CRC checksum. upon every boot/reset Netos recalculates CRC and compares with the stored one. If the CRC do not match Netos assumes NVRAM sector has been corrupted and rests it to defaults. This is how you end up with default MAC.
You can change NVRAM parameters including MAC from a serial dialog which is available when module boots. However you may have disabled it if you are using serial port to talk to some other HW. In this case you would need to reprogram MAC by writing an application that sets up MAC address in NVRAM (make sure it includes ftp server as well to update flash on the next step). FLASH that app in to module, it will update MAC then, re-flash you standart app.
What you have to figure out next is why bunch of your modules end up with corrupt NVRAM/FLASH. This would normally happen if the module will lose power or reboot during FLASH write (NVRAM write) operation.
Perhaps you have power supply stability issues. Also does your application perform many writes to NVRAM? perhaps you need to minimize that or implement a backup NVRAM sector to copy it when the original one gets corrupt.