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.

MSP432E401Y: Debugging memory issues with the TCP/IP stack and LWIP

Part Number: MSP432E401Y
Other Parts Discussed in Thread: SYSCONFIG,

Tool/software:

I am having some memory allocation related problems with an application I developed for the MSP432.  I want to be able to set breakpoints inside the LWIP TCP/IP stack, and view some of the stack variables like "lwipstats".  I've added the lwip source code to my project, and enabled DEBUG, but I am still unable to set breakpoints in the lwip source.  

What is the best way to setup a project for full debug of the app with LWIP?  This app is based on one of the SimpleLink example HTTP client projects and uses the TI-RTOS.

Is there a way that I can include all the source code in my project and build everything together without the external project dependency?

  • Hi,

      Sorry, I'm currently on vacation for the entire week. I will look into your problem when I get back. Please expect delays in my response. 

  • I am having some memory allocation related problems with an application I developed for the MSP432.  I want to be able to set breakpoints inside the LWIP TCP/IP stack, and view some of the stack variables like "lwipstats".  I've added the lwip source code to my project, and enabled DEBUG, but I am still unable to set breakpoints in the lwip source. 

    If you want to debug a lwIP example then you would need to modify the lwipopts.h file. See below example. Please note that the stock lwIP examples in the MSP432E SDK uses RAW API without RTOS. 

    #define DEBUG
    //*****************************************************************************
    //
    // ---------- Debugging options ----------
    //
    //*****************************************************************************
    #ifdef DEBUG
    #define U8_F "c"
    #define S8_F "c"
    #define X8_F "02x"
    #define U16_F "u"
    #define S16_F "d"
    #define X16_F "x"
    #define U32_F "u"
    #define S32_F "d"
    #define X32_F "x"
    extern void UARTprintf(const char *pcString, ...);
    #define LWIP_PLATFORM_DIAG(msg) UARTprintf msg
    #define LWIP_PLATFORM_ASSERT(msg) UARTprintf("ASSERT FAIL at line %d of %s: %s\n", __LINE__, __FILE__, msg)
    #define LWIP_DEBUG 1
    #endif

    //#define LWIP_DBG_MIN_LEVEL LWIP_DBG_LEVEL_OFF
    #define LWIP_DBG_MIN_LEVEL LWIP_DBG_LEVEL_OFF
    //#define LWIP_DBG_MIN_LEVEL LWIP_DBG_LEVEL_WARNING
    //#define LWIP_DBG_MIN_LEVEL LWIP_DBG_LEVEL_SERIOUS
    //#define LWIP_DBG_MIN_LEVEL LWIP_DBG_LEVEL_SEVERE

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

    //#define ETHARP_DEBUG LWIP_DBG_ON // default is OFF
    #define NETIF_DEBUG LWIP_DBG_OFF
    //#define PBUF_DEBUG LWIP_DBG_OFF
    //#define API_LIB_DEBUG LWIP_DBG_OFF
    //#define API_MSG_DEBUG LWIP_DBG_OFF
    //#define SOCKETS_DEBUG LWIP_DBG_OFF
    #define HTTPD_DEBUG LWIP_DBG_OFF
    //#define ICMP_DEBUG LWIP_DBG_OFF
    //#define IGMP_DEBUG LWIP_DBG_OFF
    //#define INET_DEBUG LWIP_DBG_OFF
    //#define IP_DEBUG LWIP_DBG_ON
    //#define IP_REASS_DEBUG LWIP_DBG_OFF
    #define RAW_DEBUG LWIP_DBG_OFF
    //#define MEM_DEBUG LWIP_DBG_OFF
    //#define MEMP_DEBUG LWIP_DBG_OFF
    //#define SYS_DEBUG LWIP_DBG_OFF
    //#define TCP_DEBUG LWIP_DBG_ON
    #define TCP_INPUT_DEBUG LWIP_DBG_OFF
    //#define TCP_FR_DEBUG LWIP_DBG_OFF
    //#define TCP_RTO_DEBUG LWIP_DBG_OFF
    //#define TCP_CWND_DEBUG LWIP_DBG_OFF
    //#define TCP_WND_DEBUG LWIP_DBG_OFF
    #define TCP_OUTPUT_DEBUG LWIP_DBG_OFF
    //#define TCP_RST_DEBUG LWIP_DBG_OFF
    //#define TCP_QLEN_DEBUG LWIP_DBG_OFF
    //#define UDP_DEBUG LWIP_DBG_ON // default is OFF
    //#define TCPIP_DEBUG LWIP_DBG_ON
    //#define PPP_DEBUG LWIP_DBG_OFF
    //#define SLIP_DEBUG LWIP_DBG_OFF
    //#define DHCP_DEBUG LWIP_DBG_ON // default is OFF
    //#define AUTOIP_DEBUG LWIP_DBG_OFF
    //#define SNMP_MSG_DEBUG LWIP_DBG_OFF
    //#define SNMP_MIB_DEBUG LWIP_DBG_OFF
    //#define DNS_DEBUG LWIP_DBG_OFF

    #endif /* __LWIPOPTS_H__ */

    What is the best way to setup a project for full debug of the app with LWIP?  This app is based on one of the SimpleLink example HTTP client projects and uses the TI-RTOS.

    The stock TI-RTOS based Ethernet examples in the SDK use NDK as the TCP/IP layers. While it is possible to use lwIP stack with TI-RTOS for sequential API, I have no experience with this combination. It seems like you got it working and just needed some visibility into debugging. Not sure if you have played with the lwipopts.h file as mentioned above. That is the only thing I know of to enable debugging into lwIP source code. I will suggest you reach out to lwIP forum for other suggestions if the above does not give you what you want. 

  • Hi Charles,

    Thanks for responding to my message.  I think I should state my question differently.

    I am having what appears to be a memory allocation issue when connecting to a secure web server using the HTTPClient_connect() function.  It was my understanding that the SimpleLink framework used LWIP as the TCP/IP stack.  All the parameters in SysConfig for the stack match the options in the lwipopts.h file.  Could you please explain how LWIP fits into the framework?  My application is based off the HTTPClient example using the TI-RTOS.

    What I am seeing is the HTTPClient_connect call fails with error code -2006, which is an invalid parameter error.  I have tracked this down to something deep in the DNS resolution of the URL passed to the function.  If I change this to the IP address of the server the function returns a -105 error with is a lack of buffers error.  I am trying to find the root cause of these issues and felt it would be useful to see the lwipstats structure.

    This error does not always occur.  If I restart the program multiple times, I find that everything occasionally works.  I have also found that testing this on my home network, which has less background traffic, the call is successful more often.

    I have tried to increase the stack sizes, memory pool buffers, heap space, and don't seem to make any progress on figuring out root cause.  Searching these forums turns up many threads with similar -2006 errors, but this is usually due to an error in older versions of the NDK.  I am using the latest libraries available for the MSP432E401Y.  I have also been watching the NDK memory with the ROV during debug and do not see any memory problems.

    I need advice on how to find this error.  Can you suggest any other methods to isolate this issue?

    Thanks,

    Rob

  • Hi,

      Are you referring to the example in C:\ti\simplelink_msp432e4_sdk_4_20_00_12\examples\rtos\MSP_EXP432E401Y\ns\httpget that uses HTTPClient_connect call to connect with a server? If this is the example or the like you are basing off then as stated this is an example built on TI's NDK TCP/IP, not lwIP. See below .syscfg. All of these things are NDK, not lwIP. I don't think you will find an API that is called HTTPClient_connect in lwIP library. You can find all lwIP APIs (RAW, Sequential, Socket) in https://www.nongnu.org/lwip/2_1_x/group__api.html.

      Please note that tomorrow and Wed are Christmas holiday for TI and expect delays in response,  

     

  • Yes, my application is using the NDK.  I guess I mispoke about LWIP.  I thought it was being used under the NDK to implement the stack.  I understand now that I am not using LWIP.  I am still having the memory problems I describe.  Can you suggest any other methods to help debug this issue?  The -2006 error code is misleading.  I know the parameters are correct because the call completes successfully sometimes.  I also get a different error, -105, when using an IP address instead of a URL.  What causes this?  What memory is the  ENOBUF (-105) error referring to?  How can I increase the amount of memory available to prevent the ENOBUF error?  

  • Yes, I have seen that thread.  I tried reducing the size of the PBM frame and the stack stops working.  I am unable to receive a IP address through DHCP.  I haven't debugged this in detail, but anything less than 1536 causes this to fail.  I also tried other sizes and found issues with SNTP as well.  When I go back to the original values, DHCP and SNTP works, and my app still occasionally works, but fails mostly.  I agree, I think this issue is related to PBM buffers.  

    That person asked a few questions about the PBUF functions.  Can you answer those questions?  I'm forcing the mmAllocs the same way as he did, but nothing works when I do that.  What could be the difference?  Why can't the stack run with smaller PBM buffers?

    I would like to try some changes to the pbm.c file.  How can I do that?  Do I just copy the source code into my project and then edit?  How will the linker resolve to my modified function, and not the one in the library?

  • That person asked a few questions about the PBUF functions.  Can you answer those questions? 

    Hi Robert,

     As much as I'd like to answer these questions, I myself is not an expert with sufficient knowledge in how layers of NDK works. I will search to see if similar posts can be found to may provide some clues. 

    I'm wonder if you are disconnecting and then connecting the client to the server many times throughout the runtime and result in fail with error? What if your client only calls HTTPClient_connect one time to connect to the server, does it fail? 

    I would like to try some changes to the pbm.c file.  How can I do that?  Do I just copy the source code into my project and then edit?  How will the linker resolve to my modified function, and not the one in the library?

    Normally, you should be able to simply copy the pbm.c or other files to your current project. You may need to resolve some head file paths. The linker will pick the functions from the source code instead of the library. At least this what I did before for a different device instead of modify the source code in the library and rebuild the library.