ipcfg_get_mac(0, mac); always returns 00:00:5E:FE:03:03

[CarlFST60L]

Hi,

Can someone tell me why this always returns the same mac address on every device I use? (Bascially a MCF52259EVB, MQX 3.6.1, CW7.2)

void GetMacString(char *ptmp){ _enet_address mac = {0}; if(ipcfg_get_mac(0, mac) != TRUE) {  sprintf(ptmp,"MAC ERROR\n");  } else {  sprintf(ptmp,"%02X-%02X-%02X-%02X-%02X-%02X\n", mac[0], mac[1], mac[2], mac[3], mac[4], mac[5]);   } }

 output:

MAC : 00:00:5E:FE:03:03

[jpa]

This is much too late to be of any use to you, but for the next guy...

It appears that the MAC address that's set and returned by default (by the BSP) is a combination of a constant (for the first 3 octets) and the least significant three bytes of the second parameter passed to ENET_get_mac_address().  The examples I've seen usually pass the IP address as the second parameter.   So your IP address is probably xxx.254.3.3.  

See mqx\source\bsp\(your board)\enet_ini.c or init_enet.c and look for _bsp_get_mac_address.  {The guy that changed the name from enet_ini.c to init_enet.c for JUST the K60 BSP ought to get a dope slap.}

You can set your own MAC by skipping the call to ENET_get_mac_address and calling ipcfg_init_device() with your intended MAC address.  If your design has a MAC address stored somewhere, you can write a new _bsp_get_mac_address function (in your BSP)  to retrieve it and return it.   YMMV

JPA

[CarlFST60L]

Does the Ethernet chip come with a MAC address? or you have to buy a range? i.e. does the 52259EVB or 52259demo or TWR52259 Ethernet chips have a MAC in them? Should MQX not be using this if it does?

[jpa]

In my instance, the TWR-SER board and M52259EVB boards came with stickers that had a MAC address printed on them.  So presumably you don't need to purchase a MAC address to use those.  Your own design will be a different matter.

As far as I could tell, there's no non-volatile memory inside a typical Ethernet PHY, and no FLASH memory designed onto the TWR-SER card that would be able to store the MAC address.  Since the processor boards and the TWR-SER cards are sold separately, they have no advance knowledge of each other.  The only non-volatile storage is the printed sticker, requiring human-machine-interaction to transfer the data from the printed sticker into your program - in short, you have to type it into your code and use the function calls shown. 

Under the circumstances, I don't have any major qualms with what Freescale/Embedded Access did with the MAC address...they came up with a method that will generate a pseudo-unique MAC address that will work for most experimenters running the device on a private network.  I just wish it was better documented so I wouldn't have to go tracing through the code to figure out what it's really doing. 

JPA

[DavidS · Accepted solution]

Hi JPA, et al.,

Good feedback by the all.

I'll recommend we add in an explanation of how and why we are creating the MAC address the way MQX is in the MQXRTCSUG.pdf.

It would be good to add notes to the example code as well just to indicate that customer code should be creating/getting their own MAC address and not our example MAC that is based on portion of MAC and IP Address.  The assumption for the examples I think is that is several demo's were to be created on one network that the static IP addresses would be unique and therefore the example MAC address returned would be unique.

The MAC modules do not have a unique hardcoded #.  They have register that needs to be initialized.  MAC #'s are up to customer to implement but good observation that the TWR cards have a MAC label.  I'll have to inquire about that and get back to you.

Sorry for any hassles.

Regards,

David