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.

Problem with MAC ethernet (and Exosite) on XM4C rev0 silicon

Other Parts Discussed in Thread: TM4C129ENCPDT, EK-TM4C1294XL

Please read as well the third post of this thread.

Good afternoon.

We are checking/working our custom tm4c129ENCPDT board (actually xm4c rev) and we tried to run the qs_iot example.

If we run the example in the EK-TM4C1294XL launchpad the program seems to run ok. 

However if we try to run it on our board, the program get stuck, after calling:

//
// Initialize the exosite connection.
//
    exoHAL_ExositeInit();

in the exoHAL_ReadUUID function, which is called on the Exosite_Init function.

//
// Initialize Exosite layer to allow Exosite-based user commands later.
//
    Exosite_Init("texasinstruments", "ek-tm4c1294xl", IF_ENET, 0);


It seems to be a malfunction of the silicon/library.

Please, could TI confirm our suspicions.

Thank you

  • Hi,

    Each device that runs with Exosite must have it's unique identifier approved (white listed) under a client model and vendor, in this case this it is TI and the Connected LaunchPad. This uses Exosite's provisioning interface to then register, complete ownership, and assign an Exosite CIK to the device.  If you are running this code on your own hardware, the identifier wouldn't be included for the Connected LaunchPad model.

    Provisioning information: https://support.exosite.com/hc/en-us/articles/200308457-Provisioning-Overview

    There are two options.  

    1. Add a 'generic' device in your web portal and manually copy the CIK to your firmware.  You'll have to look into the code more and see where / how it stores this CIK.  This would then make it not use Exosite's provisioning interface and just be a generic device.  You'll have to add all the of data ports manually in the web portal also, but you can accomplish the same thing.

    2. Get your own Vendor account from Exosite, create your own client model, and then insert these parameters into the provisioning code here (Exosite_Init()).

    Vendor/Whitelabel accounts: https://support.exosite.com/hc/en-us/sections/200054894-Vendor-and-Whitelabel-Account-Documentation

    Thanks,

    -Mike

  • Thank you Mike.

    Very interesting (and helpful) information.

    However, for the moment is something HW related. For example, we realized, that with the enet_io example, the program  runs on the Launchpad EK-TM4C1294XL board (which has a rev 1 silicon), however it doesn't on our rev 0 silicon board.

    It get stuck checking the MAC device in the instruction SysCtlPeripheralReady(SYSCTL_PERIPH_EMAC0).

    Besides, the MAC address for these ICs was not programmed when we received them.

  • Ok, I see now where your issue is.  I'll let the TI experts help you out with this issue.

    Thanks,

    -Mike

  • Please, could somebody from TI confirm these problems?

    Thank you.

  • Hi, there. Sorry for the late reply.

    We had an internal discussion about the issue you reported and we do not think it a rev 0 vs rev 1 issue. I would suggest first checking following.

    (1) Compare the schematic of your custom board with the Launchpad EK-TM4C1294XL board to see if there are difference in the power, ground and clocks hookups.

    (2) Check the DID register for you MCU on your board to see if the device configuration is the same as the one on EK.

    Normally, we do not program the MAC address on the device we ship. You need to do it your self.

    Thanks and regards,

    Zhaohong

    .

     

  • Thank you for the reply.

    Zhaohong Zhang said:

    We had an internal discussion about the issue you reported and we do not think it a rev 0 vs rev 1 issue. I would suggest first checking following.

    (1) Compare the schematic of your custom board with the Launchpad EK-TM4C1294XL board to see if there are difference in the power, ground and clocks hookups.

    Actually, we cloned your Ethernet circuit from your DK–TM4C129x Development Kit when we were desinign the board to avoid these issues. The circuit is exactly the same.

    Zhaohong Zhang said:
    (2) Check the DID register for you MCU on your board to see if the device configuration is the same as the one on EK.

    The registers in our boards are:

    SYSCTL_DID0 0x100A0000 Device Identification 0 [Memory Mapped]


    SYSCTL_DID0_VER 001 DID0 Version 
    SYSCTL_DID0_CLASS 00001010 Device Class 
    SYSCTL_DID0_MAJ 00000000 - SYSCTL_DID0_MAJ_REVA Major Revision 
    SYSCTL_DID0_MIN 00000000 - SYSCTL_DID0_MIN_0 Minor Revision


    SYSCTL_DID1 0x102DC06C Device Identification 1 [Memory Mapped]


    SYSCTL_DID1_VER 0001 DID1 Version 
    SYSCTL_DID1_FAM 0000 Family 
    SYSCTL_DID1_PRTNO 00101101 Part Number 
    SYSCTL_DID1_PINCNT 110 Package Pin Count 
    SYSCTL_DID1_TEMP 011 Temperature Range 
    SYSCTL_DID1_PKG 01 Package Type 
    SYSCTL_DID1_ROHS 1 RoHS-Compliance 
    SYSCTL_DID1_QUAL 00 - SYSCTL_DID1_QUAL_ES Qualification Status

    In the EK board we have the registers are 

    DID0
    0x100A0001

    DID 1
    0x101FC06C

    So as you can see, since it is working on the EK board, and not on ours, we are quite sure that probably it is a silicon revision issue.

    We have bought 20 of this ICs, and the distributor provided us with this rev0 version. Is it possible to replace them with a newer version to test them?

    Thank you.