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.

TM4C1294NCPDT: tm4c1294ncpdt

Part Number: TM4C1294NCPDT

We have designed our own custom hardware based on TM4c1294ncpdt.   Recently in some of the boards we are able flash the code and mac address.  But the micro hang when the ethernet is initialized( lwIPInit).  Some of the micros are working.  Any idea what could be the issue.  Your help will be appreciated

Regards,

Ramesh

  • Hi,

      You have not provided enough information. But from what you described it may be more a board level issue. Please answer some questions for me so I have a better understanding. 

      - Will the same software run on the LaunchPad? Will you see the problem?

      - How many boards are having the problem and what is the percentage?

      - You stated some micros are working. I assume they never fail, correct?

      - For the bad boards, have you tried to use a different Ethernet cables. Does it make a difference?

      - What do you mean by 'hang'? After it hangs and if you use the debugger to connect to the target, where does the processor land? Perhaps the processor is waiting for some status ( PHY link-up status) to change or something else?

      - Does the bad board always fail no matter what? Does it work at least once?

      - Can you use wireshark to capture any traffics for the bad boards? 

      - Can you do a ABA swap test? Since you said some boards work and some don't. Swap out the MCU from the bad board to a good known board? Does the good board continue to work or fail? Next swap the MCU in the good known board to the bad board? Does the bad board continue to fail or work?

  • Hi 

    Thanks for the quick response.  Reply below

      - Will the same software run on the LaunchPad? Will you see the problem?

    It works fine in Launchpad. No issues

      - How many boards are having the problem and what is the percentage?

    out of 5 boards 2 are working

      - You stated some micros are working. I assume they never fail, correct?

    I suspect micro issues

      - For the bad boards, have you tried to use a different Ethernet cables. Does it make a difference?

    I did not connect Ethernet cable at all.  I am trying to run the other functions.  In working board while debugging. the code goes over lwipinit and execute the further code.  But in nonworking board execution won't go beyond lwipinit. I check this by updating a variable for every step and the variable is updated just before lwip init and stops there.  If i run a code without ethernet code it works fine. 

      - What do you mean by 'hang'? After it hangs and if you use the debugger to connect to the target, where does the processor land? Perhaps the processor is waiting for some status ( PHY link-up status) to change or something else?

    As I mentioned the code stuck in lwipinit.  May be it is waiting for some status.  But same code works fine launchpad  and the working board  without ethernet cable connected.  Usually it can stuck because of mac address not programmed.  But in this case we have programmed MAC address

      - Does the bad board always fail no matter what? Does it work at least once?

    Board always fails.

      - Can you use wireshark to capture any traffics for the bad boards? 

    As of now in debugger the variables are not updated and it get stuck and other functionality of code is not working

      - Can you do a ABA swap test? Since you said some boards work and some don't. Swap out the MCU from the bad board to a good known board? Does the good board continue to work or fail? Next swap the MCU in the good known board to the bad board? Does the bad board continue to fail or work?

    It is not possible to swap since it is very difficult to de-solder the ic from board without damaging the ic.

    Regards,

    Ramesh

  • Attaching a screenshot to understand the issue better

    I am updating dbnctimer before and after lwip. Last update to dbnctimer is 11.  Actually after lwip it will be loaded with 12 and beyond that it continuously incremented.  But it stuck at lwip and did not change in debugger.

  • Hi,

      Can you single step into LwIPInit to see what line of code is stuck?

      I see you use static IP. Can you try a stock TivaWare Ethernet example such as enet_lwip or enet_tcpecho_server? Both of them will call LwIPInit with DHCP Will you see the problem? You need to connect the board to a network with DHCP server in order to run the example. 

  • Hi,

    We single stepped through and the code stuck at  a while loop inside LWIPinit

    • if(MAP_SysCtlPeripheralPresent(SYSCTL_PERIPH_EPHY0))
      {
      //
      // Yes - enable and reset it.
      //
      MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_EPHY0);
      MAP_SysCtlPeripheralReset(SYSCTL_PERIPH_EPHY0);
      }
      else
      {
      //
      // Internal PHY is not present on this part so hang here.
      //
      while(1)
      {
      }
      }
      }

    Attaching the screen shot

  • This is a different problem.  I usually do not single step.  1st time I single stepped to  see a strange behavior in CCS.  The execution goes up and down for some reason.  Attaching the video.   

  • attaching the video

  • Hi,

      The reason that it goes up and down is because you have optimization turned on. Normally by default the optimization is set to 2. I usually turn off the optimization during software development like below. It will be easier to debug the code such as single stepping so the code will not jump around. Once the firmware development is complete, I will then turn on the optimization for final release. 

  • Hi,  

      One more thing to debug your issue. 

    - Take a screenshot of your System module registers. I want to see if the all the Ethernet related components are present. Below is what I see on the LaunchPad highlighted in yellow. Can you show the settings of the registers on your non working boards and your working boards. Are there differences between them?

  • Please also take pictures of the chips that has have issues during lwIPInit() where it is stuck due to PHY not present. I want to read the marking on the chip. Please do so as well for the working boards so we can investigate and compare. 

  • Screenshot of system module registers and picture of chip attached

  • The print on the IC is not very clear after the IC is assembled and cleaned with IPA solution.  So I took the picture of IC before assembly

    We have assembled around 3 boards  and all have same issue.

    Today I read the Device Identification 1 (DID1) register from the MCU and it read as 0x1019C06E in the faulty board.  The partno. is 0x19 . 

    I read the same register in evaluation board and DID1 is 0x101FC06E and part number is 0x1F.  TM4c1294ncpdt data sheet it is mentioned as 0x1F only.  I am not sure which is part number 0x19?

    I feel the print on the MCU seems to be wrong!  Can you  confirm?

    Regards,

    Ramesh

  • Hi Ramesh,

      Thank you for providing the information. We will investigate and get back with you.

  • Hi Ramesh,

      While we are investigating, can you please tell me where you source these parts? From some brokers or TI directly?

      Please also take a picture of the MCU on the boards that are working so we can compare. 

  • We usually buy from Mouser.  Since there was a shortage in market we procured from some local brokers in Bangalore.  Picture of working MCU attached.

  • Please ignore the previous  message. It is kcpdt  version.

    Regards,

    Ramesh

  • Picture of working TM4c1294ncpdt attached.

    Regards,

    Ramesh

  • Hi,

      Is this working chip also from a local broker or Mouser? Also this picture has most of the markings after 07C not visible. Can you provide the full marking?  We are currently investigating the TM4C1294NCPDT chips in the tray that you showed in the prior picture.

  • Hi,

      Our investigation shows the marking on the various chips in the tray do NOT correspond TM4C1294NCPDT. Since they are not a TI source material, we can not do anything about it as we do not know how the units were handled or if any malicious things were done while out of our custody.