• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 1105 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.

TMS570LC4357: MAC Address in series production

Andreas Arnold
Prodigy 100 points

Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

Hello,

until now we had assigned MAC Addresses on our prototypes manually via HALCOGEN. But now we are ready to start pre-series production of a controller board which uses the TMS570LC4357 Controller. We have an Ethernet interface on the board and we have a MAC address block assigned to our company.

During the production there will be an boot loader installed on the processor via JTAG. This boot loader shall be the same on any produced board. But the download file does not contain a MAC address as it shall be individual on every board.

How can the individual MAC Address assigned in an automated process to any controller board? Is there a tool available? Where is the MAC address stored (which memory)? And is it writeable only once?

Thanks for your help!

Regards, Andreas

  • 0
    TI__Guru 72500 points

    The MAC address generated by HALCoGen gets put in the file sys_main.c:

    uint8	emacAddress[6U] = 	{0xFFU, 0xFFU, 0xFFU, 0xFFU, 0xFFU, 0xFFU};

    Since it is defined outside of function scope and not defined as "const", it is stored in RAM and initialized by the auto_init function before running to main. You can overwrite the value in main before calling EMACHWInit().

    Now, the hard question, how to make unique EMAC addresses. If they need to be sequential numbers, you will have to create some tool to do that. If you have enough space (MAC address range), and the addresses do not need to be sequential, you might be able to use the information in the DIE ID register to create a unique address. You may not need all 56 bits. If you want to use this let me know and I will try to identify the minimum bits necessary to insure a unique address.

  • 0
    Intellectual 940 points
    You can use external MAC Address chip. For sample - DS2502-E48
    This is valid, registered, Unique MAC Address source
  • 0 in reply to Bob Crosby
    Prodigy 100 points
    Bob, manipulating the sys_main.c would not be applicable, because it would require a new build for any board. Additionally it would change the checksum of the download file. This is not allowed on a safety system like ours.

    Using the Die Identification would require to develop a complex algorithm that calculates that information down to a given range AND ensures that it stays unique. I will have a closer look to it.

    Another idea would is to use our external EEPROM where we can write the MAC address as configuration during the production test. We have to discuss about this internally.
  • 0 in reply to Vladimir Romanov
    Prodigy 100 points
    Vladimir, thanks for this input. We will have a closer look to it.
  • 0 in reply to Andreas Arnold
    Intellectual 940 points
    You can calculate CRC32 as postbuild step and modify application image. I implement this way. After compilation I update compilation date & time, calculate CRC32 and include this CRC32 into application image. Bootloader check CRC32 before call application. My image has small area what not included in CRC32 calculation. In this area I can store additional settings.
    You can update static variables values after build using gdb from command line.

    "%ARM_TOOLS%\bin\arm-none-eabi-gdb" --write %BASE_NAME%.tmp_elf --batch ^
    -ex "set variable flash_info.flash_crc=0x%CRC%" ^
    -ex "set variable flash_info.compile_year=%BUILD_YEAR%" ^
    -ex "set variable flash_info.compile_month=%BUILD_MONTH%." ^
    -ex "set variable flash_info.compile_day=%BUILD_DAY%." ^
    -ex "set variable flash_info.compile_hour=%BUILD_HOUR%." ^
    -ex "set variable flash_info.compile_min=%BUILD_MIN%." ^
    -ex "set variable flash_info.compile_sec=%BUILD_SEC%."
    if errorlevel 1 (
    echo Can't update %BASE_NAME%.tmp_elf with %errorlevel%
    exit /b %errorlevel%
    )
  • 0 in reply to Vladimir Romanov
    TI__Guru 72500 points
    Vladimir,
    Thank you for your suggestions. You are a great asset to this forum, we appreciate your help.
  • 0 in reply to Andreas Arnold
    TI__Guru 72500 points
    Hi Andreas,
    I did not explain well what I meant by changing sys_main.c. What I suggest is that you can overwrite the value generated in HALCoGen in sys_main.c before calling EMACHWInit(). One way would be to check a location in bank 7, or the customer OTP space that you could program in a separate step. (Use an object file that is auto-generated with an incrementing number.) The program for the main memory space would be the same for every device and the CRC would be constant.

    A variation of that idea would be to check a location in bank 7 or the OTP. If it is blank, then run a routine that is waiting for input from a test bench (perhaps using the EMAC and a default address). Your test fixture would provide the unique address. The routine in the device would program the new address into bank 7 or the OTP. The next time you power cycle, that location will no longer be blank, so the initialization routine is skipped. This does require that you embed parts of the F021 flash API in your application. Have you considered using the FEE driver to emulate EEPROM, or are you already using the bank 7 data flash for something else?
  • 0 in reply to Bob Crosby
    Prodigy 100 points

    Bob, thanks for the input. We are still not sure which way we will go. Sure is that we will use an external EEPROM. Then there are two options:

    1. This EEPROM Chip might be preflashed before soldering
    2. As you proposed: we might write a routine that checks the EEPROM and if empty a valid MAC address is provided to the uC via serial interface.

    In both cases the MAC Addresses will be taken from some kind of database (e.g. CSV-File), which links the MAC-Address to the board serial number. This is then for the further production documentation.

    Regards, Andreas