LAUNCHCC3220MODASF: Assistance needed to implement PPP via GSM Modem on CC3220MODAF

Hi,

I am attempting to implement PPP on the CC3220 by invoking certain functions following the AT command "ATD*99#\r\n". Could you please verify if my approach to the PPP implementation is correct?

   void pppInit()
{
    SlNetCfgIpV4Args_t ipV4;
    uint16_t len = sizeof(ipV4);
    uint16_t dhcpIsOn;
    int32_t status;


    // Initialize Network interface
    status = SlNetIf_init(SLNETIF_ID_1);
    if (status != 0) {
        Display_printf(NULL, 0, 0, "PPP interface initialization failed\n");
        return;
    }

    status = SlNetSock_init(0);
    if (status != 0) {
        Display_printf(NULL, 0, 0, "Socket initialization failed\n");
        return;
    }
    status = SlNetIf_add(SLNETIF_ID_1, "PPP",&pppConfig, 5);
       if (status != 0) {
           Display_printf(NULL, 0, 0, "Adding PPP interface failed\n");
           return;
       }

    // Start PPP
    if (sl_Start(NULL, NULL, NULL) < 0) {
        Display_printf(NULL, 0, 0, "PPP start failed\n");
        return;
    }

    Display_printf(NULL, 0, 0, "PPP started successfully\n");

    sleep(3);
    // Get IP address
    if (sl_NetCfgGet(SL_NETCFG_IPV4_STA_ADDR_MODE, &dhcpIsOn, &len, (unsigned char *)&ipV4) == 0) {
        Display_printf(display, 0, 0, "CC32XX has connected to AP and acquired an IP address.\n");
        Display_printf(display, 0, 0, "IP Address: %ld.%ld.%ld.%ld\n",
                       SL_IPV4_BYTE(ipV4.Ip, 3), SL_IPV4_BYTE(ipV4.Ip, 2),
                       SL_IPV4_BYTE(ipV4.Ip, 1), SL_IPV4_BYTE(ipV4.Ip, 0));
    }

}

Hi,

No. This is not correct. NWP does dot support ppp connection. That means you cannot call any sl_ API call in relation with ppp connection.

You need to select 3rd party TCP/IP stack (e.g. LwIP, NetX, etc.) with support of ppp and integrate them into application processor by yourself.

Jan

Hi,

Can you help me choose a third-party LWIP with PPP over the serial stack? I have provided a suggestion below, please check if it is the best choice.

lwip/doc/ppp.txt at master · lwip-tcpip/lwip · GitHub

Hi,

I am sorry, but I am not expert for ppp implementation at LwIP stack. Many years ago I have created own implementation of ppp protocol. That mean I know how ppp and other supporting protocols (PAP/CHAP, IPCP) works, but without expert knowledge how to use with LwIP.

At that past you said that you used ppp at ESP. That mean you have used lwIP with ppp at ESP already.

Jan

Hi,

ESP-IDF uses the open-source lwIP lightweight TCP/IP stack. The ESP-IDF version of lwIP (esp-lwip) includes modifications such as the espnetif component for ESP hardware-specific use, which facilitates the implementation of PPP. With the CC3220, are we working with the lwIP lightweight TCP/IP stack?

Hi,

No. CC3220 have own TCP/IP stack on NWP (network coprocessor). Interface with this TCP/IP are sl_ API calls. This NWP implementation does not support ppp. But nothing prevent you run own TCP/IP stack witn ppp support at application processor. You can use IwIP, NetX or other TCP/IP stack. Choice is up to you...

Jan

hi,

"The SimpleLink MSP432E4 SDK (for MSP432E4 MCUs) comes with lwIP TCP/IP stack (./source/third_party/lwip) and examples (./examples/nortos/MSP_EXP432E401Y/lwip/)."

Can I utilize this LWIP for my application?

Hi,

Maybe. I don't have experience with such approach.

Jan

Hi,

Is there any other expert knowledgeable about this approach?

Hi,

We used LwIP in the past instead of the internal network stack but haven't used PPP (not sure if LwIP has PPP).

But, TI does not support porting and integration of an external network stack.

Regards,

Shlomi

Hi,

I am integrating a third-party LWIP by myself and encountering some linking errors while building the projects as mentioned below.

l"ti/devices/cc32xx/driverlib/ccs/Release/driverlib.a" -llibc.a 
<Linking>
 
 undefined     first referenced   
  symbol           in file        
 ---------     ----------------   
 dns_getserver ./pppos_example.obj
 ip4addr_ntoa  ./pppos_example.obj
 ppp_connect   ./pppos_example.obj
 pppos_create  ./pppos_example.obj
 sio_open      ./pppos_example.obj
 sio_write     ./pppos_example.obj
 
error #10234-D: unresolved symbols remain
error #10010: errors encountered during linking; "power_measurement_CC3220SF_LAUNCHXL_freertos_ccs.out" not built
 
>> Compilation failure
makefile:153: recipe for target 'power_measurement_CC3220SF_LAUNCHXL_freertos_ccs.out' failed
gmake[1]: *** [power_measurement_CC3220SF_LAUNCHXL_freertos_ccs.out] Error 1
makefile:146: recipe for target 'all' failed
gmake: *** [all] Error 2

Hi, 
Any update today?

Hi,

You have linking issue. It may to be related to including files, paths or something else. Who knows...

This will be up to you determine what is going on. At first step you need to understand structure of your 3rd party TCP/IP stack. After that you can start resolving all issues.

At the past I ported SNMP (v1, v2, v3) code from LwIP to CC3220. It was not a hard job, but you definitely need to know what are you doing.

btw ... what exact model of GSM modem do you use?

Jan

Hello,

We are utilizing the SIM7600G-H for our GSM modem application.
I am in the process of integrating the LWIP library from the MSP432E4 MCU SDK into the CC3220 SDK as a third-party LWIP. My goal is to develop a PPPOS example code by adding project path locations identical to the `./examples/nortos/MSP_EXP432E401Y/lwip/ethernet-based_io_control` project, However, I encountered some linking errors as mentioned previously.

Hi,

I don't understand your approach. What is a point of selecting much harder way of implementation? That SIMCom modem does supports TCP/IP over AT commands. It will be much easier to utilise this feature instead porting TCP/IP stack with ppp to CC32xx.

Jan

Hi,
Our cloud platform is the Azure IoT Hub, and we are utilizing the azure_cc32xx_4_10_01_01 SDK for cloud connectivity and device messaging. Therefore, TCP/IP over AT commands is not feasible in this scenario, and we should proceed with PPP integration on the CC3220.

Hi,

Are you really sure? Really? I don't see any reason which will prevent you to use TCP/IP over AT commands for communication with IoT hub. SIM7600 even supports TLS 1.2, HTTPs and MQTT. IoT HUB does have support MQTTs and HTTPs. Sending data via HTTPs into IoT HUB is about few lines of AT commands.

Jan

Hi,

Apologies for the confusion. Our project is nearly complete, utilizing Azure MQTT sample code (Azure SDK), Http_get (CC32XX SDK), and cloud_ota (CC32XX SDK) with WiFi connectivity. The GSM modem serves as our backup internet connection in remote areas. When employing TCP/IP over AT, I port all the code, making PPP implementation the easiest way. Am I right?

Hi,

This depends on what is your exact needs. If you need to use multiple sockets via GSM, I will say use ppp. But if you need to use GSM only for connection with IoT HUB, I will expect using TCP/IP over AT will be much easier way. Question will be where WiFi and GSM will be connected together. It can be connected above the TI MQTT library or at slNet layer (like a MSP432 have done with Ethernet and WiFi).

Jan

Hello,

In our project, GSM connectivity is used exclusively in remote areas, while Wi-Fi is preferred in other locations. The project does not support Wi-Fi and GSM connectivity at the same time and necessitates multiple socket connections for MQTT, HTTPS, and OTA updates; therefore, PPP would be a better option, correct?

Hi,

Usage of multiple sockets simultaneously using TCP/IP over AT commands may to be slightly tricky.

I am not able say which way will be better for you. It will depends on your experiences and preferences.

Jan

Hi Jan D,
Previously, you mentioned porting the SNMP code from LWIP to cc3220. Could you please share that with me? I am currently facing challenges with writing the sys_arch source file for third-party LWIP integration. Your assistance would be greatly appreciated.

Hi,

I am sorry, but I am not able share my code. But if you describe your issue, I will try to help you.

Main issue when I ported SNMP stack form LwIP to CC3220 was rewrite pbuf wrapper (snmp_pbuf_stream.c/.h) to be compatible with CC3220. Another challenge was SNMP tables works at LwIP and hardware accelerators integration for SNMPv3.

Jan

hi,
Ok, I understand. Could you please share at least which version of LWIP you used? I am utilizing this LWIP library for PPP integration, and I am currently encountering a block in sys_arch.

Hi,

I have ported SNMP only and this allowed me to remove deep dependencies from other LwIP code. This was mainly done via pbuf layer (changing from round buffers for LwIP socket to linear socket buffers for CC3220). This allowed me to not fall into trap of LwIP dependencies. At my project I use SNMP from LwIP not whole LwIP stack.

I started from LwIP version 2.1.3, but I have ported all changes from LwIP bugtrack. From this reason my SNMP code is exact same as at 2.2.0.

Jan

Hello,

I appreciate your response. I have effectively disabled third-party LWIP integration on cc3220. Are there any current discussions or threads available that address this approach?

Thank you.

Hi,

I don't understand your question. But if you are asking for threads where discussed integration of CC32xx with 3rd party TCP/IP stack, I remember to few similar thread from the past. But I am not able find them now.

Jan