Support / Knowledge Base / ConnectCore 7U (UNC20) modules running NET+OS 6.3 beeing reset to MAC 00:04:F3:00:06:35

ConnectCore 7U (UNC20) modules running NET+OS 6.3 beeing reset to MAC 00:04:F3:00:06:35

New CC7U ConnectCore 7U (UNC20) modules don't boot with old custom NET+OS 6.3 firmware, or the firmware shows always same default MAC address: 00:04:F3:00:06:35 or other malfunction of firmware due to assumption that MAC starts with 00:04:F3:.. but was changed by Digi to 00:40:9D:.. OUI
Solution
Either remove the check for FS-Forth 00:04:F3:.. OUI, or add additional check for Digi 00:40:9D:.. OUI in src/bsp/platforms/unc20/boardParams.c about line 1445. E.g. you might apply the following patch:
--- src/bsp/platforms/unc20/boardParams.orig 2012-07-18 15:04:17.984972300 +0200
+++ src/bsp/platforms/unc20/boardParams.c 2012-07-18 15:10:36.442583300 +0200
@@ -1445,9 +1445,13 @@
// Checksum?, UseNvram?, plausibility of MAC address?
if( NAReadEthBoardParams ( &Param ) // Checksum not o.k
|| !NAGetAppUseNvram() // No NVRAM used
- || ethParam.aucMacAddress[0] != defaultEthParam.aucMacAddress[0] // Not FS Manufacture code
- || ethParam.aucMacAddress[1] != defaultEthParam.aucMacAddress[1]
- || ethParam.aucMacAddress[2] != defaultEthParam.aucMacAddress[2]
+ || ( ( ethParam.aucMacAddress[0] != defaultEthParam.aucMacAddress[0] // Not FS Manufacture code
+ || ethParam.aucMacAddress[1] != defaultEthParam.aucMacAddress[1]
+ || ethParam.aucMacAddress[2] != defaultEthParam.aucMacAddress[2] )
+ && ( ethParam.aucMacAddress[0] != digiMacPrefix[0] // Not Digi Manufacture code
+ || ethParam.aucMacAddress[1] != digiMacPrefix[1]
+ || ethParam.aucMacAddress[2] != digiMacPrefix[2] )
+ )
)
{
//We have got an Error, insert default Values

how to patch: https://en.wikipedia.org/wiki/Patch_%28Unix%29

If the problem still occurs in field or during manufacturing, its probably because during change of NVRAM someone cuts the power, such that NVRAM is only partially written. This will cause NVRAM including MAC to be autocorrected to default values on next boot.
The only way to workaround this, is to implement an NVRAM mirror (to have a duplicate copy of NVRM or MAC) and take the values from the mirror in case of a wrong CRC found for NVRAM.
Last updated: Aug 08, 2017

Recently Viewed Articles

No recently viewed articles
Contact a Digi expert and get started today! Contact Us