At one point in time (approximately a year or more ago) Digi did uncover a manufacturing problem whereby Connect -C modules were shipped out with the default MAC address was incorrectly programmed into units, thus the BA:DB:AD address showed up in the serial dialog. This issue was quickly addressed and processes put into place to help ensure that this issue would not arise.
If, indeed, these modules are ‘fresh’, meaning that they have never been used to run (by way of the debugger or otherwise) an image developed a using NET+OS development kit, please contact Digi support with the serial numbers of said products. We certain want to address any possible manufacturing problems that may arise.
There is, however, another possible explanation for the MAC address to have been reset. The default application on a factory fresh module was built on NET+OS version 6.0. The BSP, provided with NET+OS versions subsequent to 6.0 (e.g. 6.1, 6.2, 6.3, etc.) are able to recognize a previous NET+OS version’s NVRAM structure and convert it. If one, for example, builds and runs an example based on 6.3, using the debugger, the NVRAM structure will be converted to a 6.3 version and re-written to NVRAM. Since the 6.3 application image is not written to flash, when debugging, if one subsequently resets (e.g. power cycles) the module it will boot the 6.0 image, currently stored in flash. Because the 6.0 image is unablle to recognize the 6.3 NVRAM structure format it will erase it and use its pre-detemined defaults (based on appconf.h), in which the aforementioned MAC address (or whatever address is specified in appfconf.h) is used.
There may be other reasons for this resetting of NVRAM, specific to the individual application, which would have to addressed on a case by case basis.
This problem first appeared a while ago. You can do a search through the forums for the previous details.
Digi has corrected the problem (according to them) for future production runs. There is a couple of ways to correct this. You can write test code to fix your ConnectME devices. There are two ways that I know of:
in bsproot.c, in the netosStartup function, I’ve added the following lines (before the netosConfigStdio() function call):
customizeReadDevBoardParams (&nvParams); /* read new settings from NVRAM */
/* TIM: test code to physically write a MAC address into the NVRAM area */
2) Use the function customizeSetMACAddress() with the correct value (as printed on the label) to correct your NVRAM section. Also, make sure that the default setting for collecting the IP is DHCP. This should correct your problems.
Please use caution when writing the DevBoardParams into NVRAM.
With my #1 above, you should only run your program ONCE. After that, rebuild your bsp and runtime application.
With my #2 above, it should only be test code. You can create a interface that will pass the ConnectME the correct MAC address, and then use the function to change it’s own MAC address.
Just a note: I’ve had better success with #1 above, than with #2.
I used the second solution to restore the MAC address. Do you know when and how Digi corrected the problem (NETOS 6.3 maybe)? I did not see any mention in the forum about this correction and it appears on recently received DIGIs.
Thanks for your help. I have finally resolved the problem.
It appeared that the flash write failed when a FastIP interrupt occured at the same time. In this FastIP handler was a flash reading conflicting with the writing. Ok it’s not very clever to read the flash at this point. But the conflict resulted by a total flash erasing, including NVRAM data.