Wrong MAC adress "BAD BAD"?

Embedded Devices NET+OS
1

Hi,
we are using DigiConnect ME C-Type with our own Software.

Today our production has found a module which works fine, but the MAC-address printed on the sticker does not match the MAC address stored in the device.
We did not change it.

Which one is the right one?

P/N (sticker) (1P)50000878-03M
MAC (sticker) 00409D-28060B
MAC (netosprog /discover) 00409D-BADBAD (bad bad? Really that bad? :wink:

How do I change the MAC address without startup dialog? Do I have to write a special application just to change it or do you have a tool program like netosprog?

Thank you for your answer,
Arthur

2

Hi,

Your custom firmware erase the NVRAM where the MAC address is stored. 00409D-BADBAD is the default MAC address automatically given when the data in NVRAM is wrong.

I have the same problem, it occurs after a flash write. I am sorry I still haven’t found a solution at this time, I use instead a menu to restore the correct MAC address.

If you have a solution, thanks to share! It occurs very often…

Paul

3

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.

Cameron
Support phone: (952) 912-3456
Support e-mail: http://www.digi.com/support/supportrequest.jsp

4

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:

  1. 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 */

#if 1
/* TIM: test code to physically write a MAC address into the NVRAM area */

nvParams.ethernetMac[3] = 0x26;
nvParams.ethernetMac[4] = 0x22;
nvParams.ethernetMac[5] = 0x2F;

customizeWriteDevBoardParams (&nvParams);

#endif

or:
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.

Tim

5

Hi Timmyb, thanks for answer.

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,

Paul

6

It was a production process problem. Don’t know when it was corrected. It was just for a short time.

Tim

7

Hello,
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.

Paul