• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 31 subscribers
  • Views 1056 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MAC address

matteo lucarelli
Genius 3265 points
Other Parts Discussed in Thread: HALCOGEN

Hi,

I'm currently working with RM48HDK and lwIP stack.

It seems that something goes wrong when I set a MAC address different form the one in the Halcogen example.

Do the HW have some hardcoded MAC somewhere?

  • 0
    Genius 3265 points

    Using the default MAC set by halcogen (00:08:EE:03:A6:6C) my interface works both using DHCP ans static address set. Setting my MAC (70:B3D5:F8:C0:00) my interface works only with static ip assing, no DHCP.


    I've tried assigning my MAC both filling the required fields in halcogen and modifing the uint8    emacAddress in the code. The result is the same.

    Do the 00:08:EE:03:A6:6C has some special meanings?

  • 0 in reply to matteo lucarelli
    TI__Mastermind 49120 points

    Matteo,

    Our EMAC expert will get back to you.

    Regards, Sunil

  • 0 in reply to matteo lucarelli
    Genius 3265 points

    also I've noted the following two lines in the emac.h:

    #define EMAC_MACSRCADDRHI_CONFIGVALUE ((uint32)((uint32)0x03U << 24U) | (uint32)((uint32)0xEEU << 16U) | (uint32)((uint32)0x08U << 8U) | (uint32)((uint32)0x00U))
    #define EMAC_MACSRCADDRLO_CONFIGVALUE ((uint32)((uint32)0x6CU << 8U) | (uint32)((uint32)0x08U))

    This are written by halcogen usign the MAC address form the "EMAC" fields.

    Seema bug or at least, although inoperative, seems a bit 'misleading.

    BTW: how the MAC address is used here? I mean: the MACSRCADDRHI is the hi part of the MAC in a reverse order but the MACSRCADDRLO contain a byte from the MAC and onother I cannot understand.

     

  • 0 in reply to matteo lucarelli
    TI__Intellectual 800 points

    Matteo,

    It ought to work with any address, there's nothing that has been hardcoded. I also remember trying with other addresses and it worked so not sure why you're having this issue. I'm unable to test it again at this moment but when I do, I will update this thread.
    Are there any changes that you have made that might affect the behaviour of the demo?

    Also, the above macros that you have mentioned are for the getConfig API that's for checking register values. The MAC address is in reverse order because that's how it's stored in the MACADDR register.

    Regards,

    Chaitanya

  • 0 in reply to Chaitanya K
    Genius 3265 points

    Hi,

    in the macros the MAC address in is reverse order exept one byte, that's different. Why?

    that's the MAC: 00:08:EE:03:A6:6C

    these are the two defines:

    EMAC_MACSRCADDRHI_CONFIGVALUE 0x03U 0xEEU 0x08U0x00U
    EMAC_MACSRCADDRLO_CONFIGVALUE 0x6CU 0x08U

    As you can see the byte=A6 is missed

  • 0 in reply to matteo lucarelli
    Genius 3265 points

    Moreover these defines can be misleading because one shoud think that changing the emacAddress var in the sys_main would be enough but for some reason the MAC inserted by Halcogen is hardcoded here too.

    How the defines are used? Is this a Halcogen bug?

  • 0 in reply to matteo lucarelli
    TI__Intellectual 800 points

    Matteo,

    There is an API called EMACGetConfigValue() where you can check the values of the EMAC configuration registers by comparing them to their values at initialization. These 2 macros are used there. They take their values from the MAC address field under the EMAC tab in the HALCoGen GUI and are not hardcoded. There is a bug in the second byte of the EMAC_MACSRCADDRLO_CONFIGVALUE macro (It's pointing to byte 2 of the EMAC instead of byte 5). Thanks for pointing this out, we'll correct it.

    As to whether it's misleading, HALCoGen takes all its inputs from the GUI, so it'd be better to make any required changes there and regenerate your code. Also, these macros aren't really used anywhere apart from the EMACGetConfigValue function so they shouldn't affect the functioning of the module.

    Regards,

    Chaitanya

  • 0 in reply to Chaitanya K
    Genius 3265 points

    Thank you for the answer.

    I agree this macro isn't really affecting anything but anyway having the MAC hardcoded from Halcogen is misleading because in a real situation having to change it recompiling the code isn't paractical at all.

    Meanwhile you're correcting the bug you should fix this too.

    Regards,

    Matteo

  • 0 in reply to matteo lucarelli
    TI__Intellectual 800 points

    Matteo,

    I see your point. As a safety requirement, it's mandatory to have these macros storing initial configuration values. We could add a comment explaining how it's used and that it needs to be replaced if IP address is changed.

    Also, are you able to run the demo with other IP addresses?

    Regards,

    Chaitanya

  • 0 in reply to Chaitanya K
    Genius 3265 points

    Sure,I have come a long way compared to the demo.

    Actually I'm using lwIP in a production environment.

    Thank you