Lost MAC Address

Embedded Devices NET+OS
1

Hi, I’m programming the Connect ME using the development kit w/ gnu. I’ve run into a few times where the MAC address on my device disappears and is replaced with all zeros. As this was happening on the JTAG version I’ve been able to fix it.
I am using the NVRAM for storage of IP parameters. I was wondering, if I was doing the NVRAM storage incorrectly could I somehow be affecting the stored MAC Address for the device.

I don’t make a CustomizeSetMACAddress call anywhere in my code.

2

There are generally a few reasons that the MAC (as well as other configuration information) is coming up incorrect.

  1. In the application file appconf.h, there is a #define for APP_USE_NVRAM. If this define is set to FALSE the application will not access NVRAM to get the device parameters (devBoardParamsType struct), but instead will use whatever values are define in the reset of the appconf.h file.
  2. If the NVRAM space has been erased or corrupted the devBoardParamsType struct is regenerated using the information provided by the appconf.h file.
  3. If you are modifying the devBoardParamType struct (boardParams.h) and have no provide functionality to convert the existing structure to your new format.

What is the serial number of one of the ME’s that you have experienced this behavior? What version of NET+OS are your working with (look at line 2 of the c:
etos60_gnu\readme.txt file)?

Cameron

3

Thanks for the quick reply. My APP_USE_NVRAM settings is set the 1. I’m not sure which one of these is the serial number, but here we go: PN: (1P) 50000878-04 C and CoO:USA 95010428A. My NET+OS version is Build 6.0.60.0.

My other thought was to move my stored values from the NVRAM to a file on the filesystem. This should put another layer between my code and directly accessing the flash.

4

In my previous posting I meant to ask for the part number of your module, which you did provide, great.

Based on the NET+OS build number of 6.0.60.0 you are working on NET+OS 6.0E. We are currently at version 6.0F, plus a patch kit. Neither 6.0F or the patch kit should have anything to do with this problem, however. You may wish to download both and upgrade. Both files can be obtained from NetSilicon’s web site (http://www.netsilicon.com/support/softwaretoolkit.jsp).

The part number you have provided indicates that you have a ME -C (or CF/W) module. What platform are you specifying when you build your BSP and application?

Cameron

5

I’ll download both updates. My build call is make PLATFORM=connectme clean/all. As for my stored data in the NVRAM, I’m writing to sector 24, which I believe was valid.

6

Have you modified the BSP? By default the connectme platform uses the last sector of flash (sector 34) as NVRAM.

Cameron

7

I think you are onto something. I’ve been using the NAFlashWrite function to write directly to sector 24, but I have my bsp set for BSP_NVRAM_LAST_FLASH_SECTOR (34).
One more question I guess. I have an older Hardware Reference which has a table and states that Sectors 23-25 are NVRAM and Sector 34 is Reserverd. Does this no longer apply?

8

The document you are referring no longer applies to our Connect ME -C modules (part numbers 50000878-03 and -04).

With the -C modules the default mapping of the flash is as follows:

  • first 64kb boot loader
  • next 832kb (default size) application image
  • next 256kb (default size) flash file system, if enabled
  • next 784kb default unallocated space
  • last sector of flash (64kb) NVRAM

The above applies to all of the Connect platforms; keeping in mind that all other Connect platforms have 4MB of flash and the sector sizes vary slightly.

By default, assuming that the bsp.h define for BSP_FLASH_DRIVER has not been changed, the customizeReadDevBoardParams() and customizeWriteDevBoardParams() functions will write into the last sector of flash (on the ME this is sector 34).

Cameron