TM4C129ENCPDT: netIPAddrHook() function doesn't execute after a specific time

Hey Charles,

Thankyou for the quick reply. I had already tried this netOpenHook(). But it goes to the callback whenever the link is connected. But the actual issue is when the network is not available. So If I use the netOpenHook(), even if there is no active network connection, it executes the function, which causes issues as per my code flow. by the way I'm using DHCP to obtain the IP address.

Hi,

  Perhaps I wasn't clear enough. netOpenHook() is a just a callback function name. What I was showing you before and please see below image again, a hook function can be called at different time. Here, I associate a hook function called my_netCloseHook() that is only called after the connection is closed. You could also call the hook function only after the IP address is acquired. What I'm trying to say is that you can call the hook function at different stages of network. By default, if you reference the example, netOpenHook() is called right after the network is opened. You can make it null when the network is open. In your hook function, you need to somehow wait until the server is up. 

hello Charles,

I understood the above reply. But what I was trying to say is that the netIPAddrHook() function executes completely fine when I connect to the network after power on. But the issue comes only if I turn on the device and kept it running for like 15 mins and then connect the network. That time the hook doesn't execute. I want to know if there is any timeout for this? If it has, is there any possibility to avoid this?

Hi,

  You might want to try SO_KEEPALIVE and see if that makes the connection open.  Below posts discuss about KEEPALIVE which will be helpful. 

https://holmeshe.me/network-essentials-setsockopt-SO_KEEPALIVE/

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/513818/so_keepalive-usage?tisearch=e2e-sitesearch&keymatch=so_keepalive#

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/513818/so_keepalive-usage?tisearch=e2e-sitesearch&keymatch=SO_KEEPALIVE#

Hello Charles,

SoKeepAlive() function is to keep the socket connection alive once it is connected, right? But my issue happens if the connection has not happened for like more than 5-6 minutes after power on. I changed the ndkTickPeriod to 50, which was 100 before and that didn't help.

From the testing I understood that this issue happens only when the device is kept running without network after power on. But If I connect the network after power on and then remove the connection, there is no issue. Even if I connect to the network afterwards it will connect without any issue.

and one more thing, I also tried the netOpenHook() and netCloseHook() functions. But the hook is not executing when the connection is established and removed. I don't know if this is something to do with the hook priority. currently it is configured in low priority. But the netIPAddrHook() gets executed in the same priority.

Hello Charles,

For more clarity,

the static void ti_ndk_config_Global_NetworkIPAddr(IPN IPAddr, uint IfIdx, uint fAdd) function inside the main_pem4f.c is not executing after some time from power on. This is the actual issue.

Hi Rahul,

  I'm not an expert in TI-RTOS NDK. Using the tcpEcho example that comes with TI-RTOS, I see the generated code in tcpEcho_perm4f.c file with the following code snippet where NC_NetStart() is started. 

/* Main Thread */
Void ti_ndk_config_Global_stackThread(UArg arg0, UArg arg1)
{
    int rc;
    HANDLE hCfg;

    ti_sysbios_knl_Clock_Params clockParams;

    /* Create the NDK heart beat */
    ti_sysbios_knl_Clock_Params_init(&clockParams);
    clockParams.startFlag = TRUE;
    clockParams.period = 100;
    ti_sysbios_knl_Clock_create(&llTimerTick, clockParams.period, &clockParams, NULL);


    /* THIS MUST BE THE ABSOLUTE FIRST THING DONE IN AN APPLICATION!! */
    rc = NC_SystemOpen(NC_PRIORITY_LOW, NC_OPMODE_INTERRUPT);
    if (rc) {
        xdc_runtime_System_abort("NC_SystemOpen Failed (%d)\n");
    }

    /* Create and build the system configuration from scratch. */
    hCfg = CfgNew();
    if (!hCfg) {
        xdc_runtime_System_printf("Unable to create configuration\n");
        goto main_exit;
    }

    /* add the Ip module configuration settings. */
    ti_ndk_config_ip_init(hCfg);

    /* add the Tcp module configuration settings. */
    ti_ndk_config_tcp_init(hCfg);

    /* add the Udp module configuration settings. */
    ti_ndk_config_udp_init(hCfg);

    /* add the configuration settings for NDK low priority tasks stack size. */
    rc = 1024;
    CfgAddEntry(hCfg, CFGTAG_OS, CFGITEM_OS_TASKSTKLOW,
                 CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&rc, 0 );

    /* add the configuration settings for NDK norm priority tasks stack size. */
    rc = 1024;
    CfgAddEntry(hCfg, CFGTAG_OS, CFGITEM_OS_TASKSTKNORM,
                 CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&rc, 0 );

    /* add the configuration settings for NDK high priority tasks stack size. */
    rc = 1024;
    CfgAddEntry(hCfg, CFGTAG_OS, CFGITEM_OS_TASKSTKHIGH,
                 CFG_ADDMODE_UNIQUE, sizeof(uint), (UINT8 *)&rc, 0 );

    /*
     *  Boot the system using this configuration
     *
     *  We keep booting until the function returns 0. This allows
     *  us to have a "reboot" command.
    */
    do
    {
        rc = NC_NetStart(hCfg, ti_ndk_config_Global_NetworkOpen, 
                         ti_ndk_config_Global_NetworkClose, 
                         ti_ndk_config_Global_NetworkIPAddr);

    } while( rc > 0 );

    /* Delete Configuration */
    CfgFree(hCfg);

    /* Close the OS */
main_exit:
    NC_SystemClose();
    xdc_runtime_System_flush();

}

You can find additional details about NC_NetStart() in the below documents. 

NDK API User's Guide. 

NDK Developer User's Guide

Reading the document, It seems that in your case, the stack considers it a fatal error and shut it down after unable to establish a connection for a long time. I don't know what is suggested below as to disable the abort upon any error will help your situation.  

2.1.4.3 Shutdown
There are two ways the stack can be shut down. The first is a manual shutdown that occurs when an
application calls NC_NetStop(). Here, the calling argument to the function is returned to the NETCTRL
thread as the return value from NC_NetStart(). Therefore, for the example code, calling NC_NetStop(1)
reboots the network stack, while calling NC_NetStop(0) shuts down the network stack.
The second way the stack can be shut down is when the stack code detects a fatal error. A fatal error is
an error above the fatal threshold set in the configuration. This type of error generally indicates that it is
not safe for the stack to continue. When this occurs, the stack code calls NC_NetStop(-1). It is then up to
you to determine what should be done next. The way the NC_NetStart() loop is coded determines if the
system will shut down (as in the example), or simply reboot.
Note that the critical threshold to shut down can also be disabled. The following code can be added to the
configuration to disable error-related shutdowns:
// We do not want the stack to abort on any error
uint32_t rc = DBG_NONE;
CfgAddEntry( hCfg, CFGTAG_OS, CFGITEM_OS_DBGABORTLEVEL,
CFG_ADDMODE_UNIQUE, sizeof(uint32_t), (unsigned char *)&rc, 0 );

hello Charles,

Thankyou for your support. But I have already tried this before and this didn't fix my issue.

I have tried this configuration by setting from main.cfg file.

I think this is some other issue.

hey Charles,

One more update. From the debug print in console. I found that some fault happens after a time of around 2.48 minutes from starting. This is what causes the issue. After this fault the hooks don't work and the network main stack also doesn't work.

I think this is due to DHCP timeout. I tried some configurations in main.cfg file, but couldn't find one. Do you have any idea on how can I disable this DHCP timeout. or how can I restart from DHCP timeout?

Hi,

Rahul Santhosh said:

I think this is due to DHCP timeout. I tried some configurations in main.cfg file, but couldn't find one.

I see in the log that you are running a HTTP GET example. If you are not getting beyond DHCP then it is a different problem from you earlier reporting. Have you tried the stock HTTP GET example from TI-RTOS?  You can download HTTP GET example from Resource Explorer from within CCS. See below. Run this example as is and see if you can get DHCP. If it works, then you can reference the .cfg. If you have the same problem acquiring DHCP IP address with the stock example then you need to look into your network and find out if there is a DHCP server on your network. You might need to contact your local IT support. 

Rahul Santhosh said:

This is what causes the issue. After this fault the hooks don't work and the network main stack also doesn't work.

Not sure why the faults. First run the stock example. It is possible that the fault is due to memory configuration (.e.g. not having enough stack or heap). See below posts which are helpful for debugging. 

Presentation to debug common TI-RTOS issue:

https://www.ti.com/content/dam/videos/external-videos/1/3816841626001/4910324181001.mp4/subassets/debugging-common-application-issues-ti-rtos-presentation-lab.pdf

TI-RTOS NDK memory management:

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/947313/faq-how-is-memory-managed-in-the-ndk

DHCP Timeout:

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/505226/handling-dhcp-client-timeout

Hey Charles,

Yes I was trying the HTTP Get example for TI RTOS. The console screenshot was from that example. So that means this fault does happens in the example too. Therefore I don't think this issue is due to memory management. I'm planning to restart the DHCP connection once the fault happens as it is possible to get the timeout event using 'StatusReportHook'. 

Hi Rahul,

  Glad that your problem is resolved! Would you be so kind to elaborate how you resolve the issue? Which hook function did you add or modify and where did you insert this hook? How did you restart DHCP? Can you please provide your code snippet? I'm sure it will benefit the community who may have the same issue. I'd like to reference your solution to others. Thanks. 

Hi Rahul,

  Thank you for your clarification that you use status value equal to 0x2 when a timeout happens.