• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 30 subscribers
  • Views 372 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: Tivaware Networking Issues.

CJ Boyer
Prodigy 20 points
Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: EK-TM4C1294XL, UNIFLASH

I've been building a simple TCP communication program using the LWIP Examples for the launchpad. I have it working fine on the launchpad, and when the custom board I will be  using came in and we go the chip installed, we ran into some issues. First we had to program the MAC address, which we figured out and got done, and expected the application to work the same as on the launchpad from that point on.z

However, We are now running into an issue where inside the lwIPInit() call the code is hanging. I was able to use a debugger to trace it to the following lines from inside lwIPInit(). 

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
//
// Enable the internal PHY if it's present and we're being
// asked to use it.
//
if((EMAC_PHY_CONFIG & EMAC_PHY_TYPE_MASK) == EMAC_PHY_TYPE_INTERNAL)
{
//
// We've been asked to configure for use with the internal
// PHY. Is it present?
//
if(MAP_SysCtlPeripheralPresent(SYSCTL_PERIPH_EPHY0))
{
//
// Yes - enable and reset it.
//
MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_EPHY0);
MAP_SysCtlPeripheralReset(SYSCTL_PERIPH_EPHY0);
}
else
{
//
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

During the MAP_SysCtlPeripheralReset(SYSCTL_PERIPH_EPHY0); the debugger loses track of where the program is, and the board becomes unresponsive. 

This only occurs on a board using a factory chip, the code works fine on the EK-TM4C1294XL launchpad we used to prototype the code. My thought is this may be a similar issue to the MAC address not being set, that there may be some setting related to EPHY0 not set by default. But I haven't been able to find much documentation on this type of problem online. So any help would be appreciated. 

  • 0
    TI__Guru**** 183806 points

    Hi,

      If it works on LaunchPad then I expect the same code to work on your custom board provided you have the same schematic on the Ethernet interface to RJ45.

    CJ Boyer said:
    During the MAP_SysCtlPeripheralReset(SYSCTL_PERIPH_EPHY0); the debugger loses track of where the program is, and the board becomes unresponsive

    Where exact is the processor program counter? Is it hanging on MAP_SysCtlPeripheralReset(SYSCTL_PERIPH_EPHY0) if that is what you meant by unresponsive? 

    - If you do a reset or power cycle do you still get stuck at MAP_SysCtlPeripheralReset?

    - What if you change the compiler optimization level, does it make a difference?

    - How many boards do you have?

    - Can you repeat the same issue on another custom board? I'm hoping it is a one-off issue on just one board. 

    - Are you running your own lwIP application program or the stock TivaWare lwIP examples? Can you try a stock TivaWare lwIP example such as enet_lwip which is a simple web server? Can you repeat the same issue on your custom board?

  • 0 in reply to Charles Tsai
    Prodigy 20 points

    When I have the debugger step into MAP_SysCtlPeripheralReset(SYSCTL_PREIPH_EPHY0) the program counter disappears, and attempting to pause or stop execution will return with a CPU unresponsive error. 

    Power Cycles will cause the same result. 

    We are building up another custom board right now, and Will most likely next week be putting code on it to see if the same result occurs. 

    This has happened with both custom lwip code modified from TIvaware examples, and with Stock tivaware examples. 

  • 0 in reply to CJ Boyer
    TI__Guru**** 183806 points
    CJ Boyer said:
    When I have the debugger step into MAP_SysCtlPeripheralReset(SYSCTL_PREIPH_EPHY0) the program counter disappears, and attempting to pause or stop execution will return with a CPU unresponsive error. 

    Can you change from MAP_SysCtlPeripheralReset to SysCtlPeripheralReset? MAP_SysCtlPeripheralReset will actually call ROM_SysCtlPeripheralReset which is the driverlib stored in ROM. I'm not sure what you mean by program counter disappears. It is probably executing code in ROM. You can look at the disassembly code to see where the program counter is. But using direct SysCtlPeripheralReset will allow easier debug because the function is compiled and stored in flash and has the debug symbols and source code for you to single step. 

  • 0 in reply to Charles Tsai
    Prodigy 20 points

    My concern is the call itself posing the issue is inside the library call. It strikes me as a bad move to edit a library and potentially run into more problems with a unique version of the library. 

    I can try to put together a sandbox program to run that call and see what happens. 

  • 0 in reply to Charles Tsai
    Prodigy 20 points

    I temporarily changed the library to call directly instead of through MAP. 
    It managed to get here in sysctl.c before showing the same symptoms. 

    Fullscreen
    1
    2
    3
    4
    5
    //
    // Put the peripheral into the reset state.
    //
    HWREGBITW(SYSCTL_SRBASE + ((ui32Peripheral & 0xff00) >> 8),
    ui32Peripheral & 0xff) = 1;
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Here is a screen grab of my disassembly one step before it went unresponsive. 

  • 0 in reply to CJ Boyer
    TI__Guru**** 183806 points

    Hi,

      What compiler and its version do you use? I don't know what ??DataTable53_ is.  I use TI Arm compiler v18.12.0.LTS with optimization level 2. The disassembly output seems to be vastly different. Having said that, if the same .out file run LaunchPad, then there is no reason to suspect the software at fault in my opinion. I still think it is more hardware related.  

      After 0x4548 is executed, where does PC go? Can you show a screenshot? I want to know if you are getting any fault or in some type of branching to itself. Sorry, I'm still not clear as to what unresponsive means. Is unresponsiveness meaning the processor is taking an exception fault or branching to itself in a endless loop? The PC has to go somewhere.  

  • 0 in reply to Charles Tsai
    Prodigy 20 points

    The reason I label what is happened as unresponsive, is because I no longer get any data from the compiler debugging screens. 

    I am using IAR Embedded Workbench 9.20.2. 

    I will rerun that and try to get more data. 

  • 0 in reply to CJ Boyer
    Prodigy 20 points

    Ok, So this is running the enet_tcpecho_server example from Tivaware. 

    So I get to the call inside the lwip library, I have edited it from MAP to just a straight call as requested for debugging purposes. 

    Then it goes into Sysctl to try and do the reset call.

    After I step forward this is what I get. Unresponsive, as I lose the program tracking, and if I try to pause or reset the chip from the ide, I get the following debug log message. I had nothing come into debug during execution of the example until this. 

    If it is a hardware issue, what should I be looking for? I personally think it is a configuration issue, as before I had this problem, the problem I had was the chip did not have a MAC address programmed on it like the launchpads do. Are there any other first time chip set up/configurations that need to be done for ethernet? 

  • 0 in reply to CJ Boyer
    TI__Guru**** 183806 points

    Hi CJ,

      - What debugger are you using? Are you using CCS? Personally, I have never seen Debug Log. In CCS, there is the console window that looks different from yours. I have neve seen error messages as such either but now I understand what you mean the CPU is unresponsive.

    -  After you see these messages, is your debugger still connected to the target? Can you stop the run or the debugger is not able to do anything? The reason I'm asking is because the error seems to suggest the debugger is not able to control the target, perhaps the debugger has lost connection to the target. The error seems to be saying the debugger is trying to stop the CPU but not successful. 

    - What debug probe do you use?

    - What is the MAC address value you program? 

    - What tool did you use to program MAC address? Can you read out the MAC address?

    - Can you try another Ethernet program like enet_lwip? This is a simple webserver example. I want to know if you will have the same issue like tcpecho. 

  • 0 in reply to Charles Tsai
    Prodigy 20 points

    As I mentioned above, I am using IAR Embedded Workbench 9.20.2. 

    The probe I am using is the IAR I-Jet. 

    The debug log occurs if I try to stop the run, or do anything. I no longer have any control or input, Besides stopping the debug. Power cycling and starting over. 

    I used Uniflash and a XDS100V2 to program the MAC Address. While it is trying to execute a program showing these issues I cannot get the probe to communicate with the chip to read the MAC, but if I load a program that does not try to incorporate the LWIP or networking calls, I can read the MAC value through uniflash. The MAC programmed and just now read from the chip through uniflash is 70-ff-76-1e-11-db.

    I loaded and ran the enet_lwip example. It shows the exact same results as enet_tcpecho example, and my own code project show once they get to the lwipinit call and the library calls contained within that. 

  • 0 in reply to CJ Boyer
    TI__Guru**** 183806 points

    Ok, I missed you mentioned IAR before. 

    Can you repeat the same problem on another custom board? How many custom boards do you have?

    Can you show PPEPHY register reading?

    What is the device marking on the chip you have on your custom board? Where did you purchase the part from? 

    I'm unable to explain your observation because both the stock example and your modified code works fine on LaunchPad. The problem only occurs on your custom board. This is why I think the problem is hardware related. 

  • 0 in reply to Charles Tsai
    Prodigy 20 points

    We have solved the issue. 

    Looking more closely at our hardware design we noticed in the manual it asks for RBIAS pin to be connected to a 4.87 KOhm resistor. The resistor we had connected had a wildly different resistance, and was either damaged, or the wrong resistor was installed. This lead to as described in the manual that the JTAG connection failed, when the Ethernet PHY part was reloaded by the LWIP library. We have swapped the resistor and now it is operating as expected. 

    My question is why does this occur, and what is that resistor actually used for? I would think if that pin needs to have a resistor even for applications that don't require Ethernet PHY, it would be included in the IC itself, as a 4.7 Kohm resistor would not take up much space. 

    Regardless, The problem is now resolved. Thank you. 

  • 0 in reply to CJ Boyer
    TI__Guru**** 183806 points

    Hi CJ,

      Glad that you resolve the problem. It didn't cross my mind that the RBIAS resistor can lead to the problem you have. Now I learn something and will bookmark this post for future reference. 

      The is an errata that requires 4.7kohm resistor to GND even if Ethernet is not used. For applications requiring Ethernet, RBIAS must be connected with a 4.87kohm resistor to GND with 1% tolerance.