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.

PROCESSOR-SDK-J784S4: Enet lwIP Shell: open <IP> <port> causes CPU load 100% with active server

Part Number: PROCESSOR-SDK-J784S4

Tool/software:

Hi TI team,

I'm testing the Enet lwIP App on a on J784S4 using the Enet LLD and LWIP stack. The board runs SDK version: ti-processor-sdk-09_02_00. I enabled the interactive lwIP shell that listens on port 23 and accepts commands like:

lwipcfg.h

#define LWIP_SHELL_APP                1

$ telnet 192.168.10.80 23

> open 192.168.10.82 80
I'm trying to connect to an HTTP server running on my host PC (192.168.10.82:80), confirmed reachable from the board (ping successful, server running with python3 -m http.server 80)

==========================
Enet lwIP App - v 0.2
==========================
EnetBoard_setupPorts: 1 of 1 ports configurations found
CPU Load: 51%
Starting lwIP, local interface IP is dhcp-enabled
No valid MAC address found in EEPROM, falling back to static address
EnetMcm: CPSW_2G on MCU NAVSS
PHY 0 is alive
EnetPhy_bindDriver: PHY 0: OUI:00a0ef Model:03 Ver:00 <-> 'generic' : OK
Host MAC address: 70:ff:76:1d:92:c1
[LWIPIF_LWIP] Enet LLD netif initialized successfully
status_callback==UP, local interface IP is 0.0.0.0
Cpsw_handleLinkUp: Port 1: Link up: 1-Gbps Full-Duplex
MAC Port 1: link up
link_callback==UP
CPU Load: 1%
status_callback==UP, local interface IP is 192.168.10.80
Enet lwIP App: Added Network IP address I/F ti0: 192.168.10.80
Initializing apps
CPU Load: 1%
CPU Load: 1%
CPU Load: 1%
CPU Load: 1%
CPU Load: 1%
CPU Load: 13%
CPU Load: 100%
CPU Load: 100%

It seems the shell application hangs after netconn_connect() call.
shell.c

static s8_t
com_open(struct command *com)
{

... sendstr("Opening connection to ", com->conn);
netconn_write(com->conn, com->args[0], strlen(com->args[0]), NETCONN_COPY);
sendstr(":", com->conn);
netconn_write(com->conn, com->args[1], strlen(com->args[1]), NETCONN_COPY);
sendstr(NEWLINE, com->conn);

conns[i] = netconn_new(NETCONN_TCP);
if (conns[i] == NULL) {
sendstr("Could not create connection identifier (out of memory)."NEWLINE, com->conn);
return ESUCCESS;
}
err = netconn_connect(conns[i], &ipaddr, port); << HANGS HERE>>


Observations:

- The board receives the SYN-ACK from the server (confirmed via tcpdump).

- CPU load spikes to 100% immediately after open is issued.

- No debug logs are visible even after setting LWIP_DEBUG and enabling relevant debug macros.

Questions:

- Is this a known issue with netconn_connect() or netconn_write() in blocking shell applications?

- How can I get full LWIP debug logs from the SDK environment?

  • Hi,

    How can I get full LWIP debug logs from the SDK environment?

    For debug prints, you also have to enable the debug flags of the stack features of interest by setting the correspondig flag to LWIP_DBG_ON. Is this being Done?

    See this section of lwip user guide for more details.

    Is this a known issue with netconn_connect() or netconn_write() in blocking shell applications?

    Let me check on this with our dev team.

    Regards,
    Tanmay

  • I have enabled debug log here. But i was not able see any debug logs.

    ti-processor-sdk-09_02_00\ti-processor-sdk-rtos-j784s4-evm-09_02_00_05\pdk_j784s4_09_02_00_30\packages\ti\transport\lwip\lwip-port\config\lwipopts_common.h

    /* ---------- Debug flags ---------- */
    #define LWIP_DEBUG (1)

    #define API_LIB_DEBUG (LWIP_DBG_ON)
    #define API_MSG_DEBUG (LWIP_DBG_ON)
    #define TCPIP_DEBUG (LWIP_DBG_ON)
    #define SOCKETS_DEBUG (LWIP_DBG_ON)
    #define TCP_DEBUG (LWIP_DBG_ON)
    #define TCP_INPUT_DEBUG (LWIP_DBG_ON)
    #define TCP_OUTPUT_DEBUG (LWIP_DBG_ON)

    #define LWIP_DBG_TYPES_ON (LWIP_DBG_ON|LWIP_DBG_TRACE|LWIP_DBG_STATE|LWIP_DBG_FRESH|LWIP_DBG_HALT)

  • We've enabled debug diagnostics by updating lwip/arch.h to route platform diagnostics via EnetAppUtils_print.
    Key modifications:

    #ifdef printf
    #undef printf
    #define printf EnetAppUtils_print
    #endif

    extern void EnetAppUtils_print(const char *pcString, ...);
    #ifndef LWIP_PLATFORM_DIAG
    #define LWIP_PLATFORM_DIAG(x) do {EnetAppUtils_print x;} while(0)
    #include <stdio.h>
    #include <stdlib.h>
    #endif


    #ifndef LWIP_PLATFORM_ASSERT
    #define LWIP_PLATFORM_ASSERT(x) \
    do { \
    volatile static int gEnetAssertWaitInLoop = 1; \
    EnetAppUtils_print("Assertion \"%s\" failed at line %d in %s\n", \
    x, __LINE__, __FILE__); \
    while (gEnetAssertWaitInLoop); \
    } while(0)
    #include <stdio.h>
    #include <stdlib.h>
    #endif

    During runtime, we see the following assertion:

    State: ESTABLISHED
    tcp_slowtmr: processing active pcb
    tcp_slowtmr: processing active pcb
    tcpip_thread: PACKET a2c9d580
    ethernet_input: dest:70:ff:76:1d:92:c1, src:c8:53:09:0d:32:77, type:800
    TCP header:
    +-------------------------------+
    |       80      |    54911      | (src port, dest port)
    +-------------------------------+
    |           1013343510          | (seq no)
    +-------------------------------+
    |           0000006540          | (ack no)
    +-------------------------------+
    |  6 |   |010010|     65535     | (hdrlen, flags (SYN ACK
    ), win)
    +-------------------------------+
    |    0x705e     |         0     | (chksum, urgp)
    +-------------------------------+
    +-+-+-+-+-+-+-+-+-+-+-+-+-+- tcp_input: flags SYN ACK
    -+-+-+-+-+-+-+-+-+-+-+-+-+-+

    State: SYN_SENT
    tcp_parseopt: MSS
    SYN-SENT: ackno 6510 pcb->snd_nxt 6510 unacked 6509
    lwip_netconn_do_connected: was_blocking:1 op_completed_sem: 0 conn->current_msg: a2c5b7d4
    Assertion "blocking connect state error" failed at line 1335 in /CascadeCore/Firmware/SDKs/ti-processor-sdk-09_02_00/ti-processor-sdk-rtos-j784s4-evm-09_02_00_05/pdk_j784s4_09_02_00_30/packages/ti/transport/lwip/lwip-stack/src/api/api_msg.c
    CPU Load: 97%


    This happens right after receiving a SYN-ACK during connect().

    Please advise on root cause or required usage pattern.

     

  • Hi,

    Sorry for delay on this issue.

    Is this issue still being obeserved?

    Regards,
    Tanmay

  • Hi,

    Issue still there. Are you able to reproduce the issue?

    Best Regards

    Abe