 |
Synergy Software Package User's Manual
|
|
Synergy Software Package User's Manual
|
The Cellular Framework module provides a high-level application layer interface for cellular modem integration in SSP. The Cellular Framework provides a common interface for the applications to interface with the cellular modems from various vendors.
The Cellular Framework provides a set of APIs to provision, configure, and communicate with the cellular network for data communication. The Cellular Framework uses the UART Comms Framework to communicate with cellular modems over a serial interface by using AT commands. The Cellular framework creates the serial data pipe over a serial interface for the data communication, leveraging the PPP WAN protocol provided by NetX™. Data communication using TCP/IP can be established over this Wide Area Network (WAN) link using NetX Application protocols, sockets or IoT protocols such as MQTT.
The Cellular Framework also provides the framework-level socket APIs to communicate with the TCP/IP stack present on-chip (inside cellular hardware module) in certain cellular hardware modules and with the TCP/IP link for the network using socket APIs.
- Note
- The following boards are obsolete and are no longer supported in SSP:
sf_cellular_nsal_nx can implement any of the four Cellular Framework modules below it.The Cellular Framework defines APIs for each of the related modules. The following descriptions explain the operation of each API.
Cellular Framework Module API Summary
| Function Name | Example API Call and Description |
|---|---|
| open | g_sf_cellular0.p_api->open (g_sf_cellular0.p_ctrl, g_sf_cellular0.p_cfg);This API function initializes and enables the Cellular module. The open function returns the Cellular control structure, uniquely identifying the instance of the Cellular framework. The Cellular framework open function accepts the Cellular module configuration as an argument, with the following parameters:- Operator Selection Mode (enumeration) - Operator Name Format (enumeration) - Operator Name (string) - Preferred Operator List (array of structures) - Time zone update policy (enumeration) |
| close | g_sf_cellular0.p_api->close (g_sf_cellular0.p_ctrl);This API uninitializes the Cellular module and disables it. It takes the Cellular control structure as an argument. |
| infoGet | g_sf_cellular0.p_api->infoGet (g_sf_cellular0.p_ctrl, p_cellular_info);This API takes the Cellular control structure as an argument and returns the following information obtained from the Cellular module: - Chipset/driver information (string) - Manufacturer name (string) - Firmware version (string) - IMEI number (string) - RSSI value (unsigned integer 16 bits) - Bit Error Rate (unsigned integer 16 bits) |
| statisticsGet | g_sf_cellular0.p_api->statisticsGet (g_sf_cellular0.p_ctrl, p_stats);This API gets the data statistics from the Cellular module. It takes the Cellular control structure as an argument and returns the following statistics: - Received packets (unsigned integer 32 bits) - Transmitted packets (unsigned integer 32 bits) - Transmit packet errors (unsigned integer 32 bits) |
| transmit | g_sf_cellular0.p_api->transmit (g_sf_cellular0.p_ctrl, p_buffer, length);This API sends the data/packet out. It takes the Cellular control structure, the data buffer and the data buffer length as an argument. The Cellular framework transmit function passes the data buffer to the PPP driver for transmission. |
| provisioningGet | g_sf_cellular0.p_api->provisioningGet (g_sf_cellular0.p_ctrl, p_cellular_provisioninfo); This API takes the Cellular control structure as an argument and returns the following parameters: - Authentication type(enumeration) - Username (string) - Password (string) - APN Name(string) - PDP Context ID (integer) - PDP Context Type (enumeration) - Airplane mode (enumeration) |
| provisioningSet | g_sf_cellular0.p_api->provisioningSet (g_sf_cellular0.p_ctrl, p_cellular_provisioninfo); This API sets the authentication credential information. It takes the Cellular control structure and the following parameters as argument to provision the Cellular module: - Authentication type(enumeration) - Username (string) - Password (string) - APN Name(string) - PDP Context ID (integer) - PDP Context Type (enumeration) - Airplane mode (enumeration) |
| networkConnect | g_sf_cellular0.p_api-> networkConnect (g_sf_cellular0.p_ctrl);This API establishes the Network connection over Cellular Network, using which the application can communicate to remote host with the help of Network stack. It takes the Cellular control structure as an argument. |
| networkDisconnect | g_sf_cellular0.p_api->networkDisconnect (g_sf_cellular0.p_ctrl);This API terminates the Network connection established using networkConnect API. It takes the Cellular control structure as an argument. |
| simPinSet | g_sf_cellular0.p_api->simPinSet (g_sf_cellular0.p_ctrl, p_pin);This API allows the application/user to change the PIN required to register on Cellular Network. It takes the Cellular control structure, old PIN and New PIN as arguments. |
| simLock | g_sf_cellular0.p_api->simLock (g_sf_cellular0.p_ctrl, p_pin);This API locks the SIM. It takes the Cellular control structure and Sim PIN as arguments. |
| simUnlock | g_sf_cellular0.p_api->simUnlock (g_sf_cellular0.p_ctrl, p_pin);This API unlocks the SIM. It takes the Cellular control structure and Sim PIN as arguments. |
| simIDGet | g_sf_cellular0.p_api->simIDGet (g_sf_cellular0.p_ctrl, p_sim_id);This API reads the Sim ID from the Cellular module. It takes the Cellular control structure as argument and returns the SIM ID read from the Cellular module. |
| commandSend | g_sf_cellular0.p_api->commandSend (g_sf_cellular0.p_ctrl, p_input_at_commmand, p_output, timeout);Send AT command directly to Cellular Modem. |
| networkStatusGet | g_sf_cellular0.p_api-> networkStatusGet (g_sf_cellular0.p_ctrl, p_status);This API gets Cellular Module Network Status information. It takes the Cellular control structure as argument and returns following parameters: - Country code (integer) - Operator code (integer) - RSSI (integer) - Cell ID (string) - IMSI (string) - Operator name (string) - Service Domain (integer) - Active Band (integer). |
| versionGet | g_sf_cellular0.p_api->versionGet (p_version);This API retrieves the version for the API using the version pointer. |
| reset | g_sf_cellular0.p_api->reset (g_sf_cellular0.p_ctrl, reset_type);Reset the cellular hardware module. |
p_input_at_commmand parameter.These APIs can be used to configure the cellular module when using an on-chip networking stack, which helps to ping particular ip address, opening and closing of scokets and also to perform socket operations like TCP/UDP data transfer.
On-Chip Networking Stack Support Cellular Framework Module API Summary
| Function Name | Example API Call and Description |
|---|---|
| open | g_sf_cellular_socket0.p_api->open (g_sf_cellular_socket0.p_ctrl, g_sf_cellular_socket0.p_cfg);This API calls the Cellular Framework's lower level open () API to Initialize the Cellular Device Driver. |
| close | g_sf_cellular_socket0.p_api->close (g_sf_cellular_socket0.p_ctrl);This API calls the Cellular Framework's lower level close () API to close the Cellular Device Driver. |
| versionGet | g_sf_cellular_socket0.p_api->versionGet (p_version);This API retrieves the version for the API using the version pointer. |
| ping | g_sf_cellular_socket0.p_api->ping(g_sf_cellular_socket0.p_ctrl, p_ip_address, count, interval_ms);This api pings the IP address provided by user. |
These API functions can be used by an application to perform data transfers using sockets. They include socket API functions which are compliant with these BSD API functions:
The following table lists the Cellular Framework specific error codes. These error codes are part of ssp_err_t.
Cellular Framework Error Codes
| Error Codes | Description |
|---|---|
| SSP_SUCCESS | Call successful. |
| SSP_ERR_CELLULAR_CONFIG_FAILED | Configuration failed. |
| SSP_ERR_CELLULAR_INIT_FAILED | Initialization failed. |
| SSP_ERR_CELLULAR_TRANSMIT_FAILED | Transmit failed. |
| SSP_ERR_CELLULAR_FW_UPTODATE | Up to date. |
| SSP_ERR_CELLULAR_FW_UPGRADE_FAILED | Upgrade failed. |
| SSP_ERR_CELLULAR_FAILED | General failure. |
| SSP_ERR_CELLULAR_INVALID_STATE | Invalid state. |
| SSP_ERR_CELLULAR_REGISTRATION_FAILED | Registration failure. |
The Cellular Framework provides a generic interface for applications to seamlessly communicate with the cellular hardware module from various vendors without the necessity of changing the applications. The framework mainly consists of a common set of APIs to interface to the networking stack and different cellular hardware modules. This section introduces the Cellular Framework's basic blocks and key features that enable you to determine whether the intended cellular application can be developed using the Cellular Framework.
With the provided API and abstraction, the applications developed for the cellular hardware module can be easily ported to use another cellular hardware module. The networking stack NetX is also integrated with the framework using the Network Software Abstraction Layer (NSAL).
The Synergy Cellular Framework consists of the following logical blocks:
The Cellular Framework provides a common set of interfaces for the application to configure, provision and to communicate with the cellular hardware module. By using these generic interfaces, the user can develop a cellular-based application using Synergy MCUs. The cellular hardware module has various configuration parameters as specified by the family of 3GPP standards. It is possible that individual device drivers and/or cellular chipsets/modules will not support configuration of all parameters. At a bare minimum, the network operator, Access Point Name (APN) and security credentials are required to make the module functional.
Network Stack Abstraction Layer
The Cellular Framework provides a network stack abstraction layer (NSAL). The NSAL is layer that connects the NetX and the cellular driver by using a (PPP) stack that is used for data communication over a WAN link.
Socket Interface Layer
The Cellular Framework provides a socket-level API for the application to interact with the on-chip networking stack present on the cellular hardware module. This requires the cellular hardware module/driver to support an on-chip networking stack and socket interface. When the application uses these APIs, it uses the on-chip networking stack present on the cellular hardware module and does not use the NSAL or the NetX and its socket APIs and does not use the Networking stack running on the Synergy MCU Group.
PPP Stack
Point to point protocol (PPP) is a widely used WAN protocol in data communication. The PPP stack is a part of the NetX stack available in the SSP. The NSAL leverages the PPP stack to communicate over the serial interface to the cellular service provider's network. PPP configuration provides options for authentication methods like PAP/CHAP; these authentication mechanisms are optional for the link establishment. The NSAL makes use of framework APIs to send/receive data from the cellular hardware module. The NSAL also allows the cellular device driver to be re-used without any specific changes to the network stack.
Cellular Device Driver (AT Command Interface For Interacting With The Cellular Chipset)
The Cellular Framework uses the AT command set to interact with the cellular modem using the serial driver. The serial interface used to interact with the modem is the UART. The UART speed used in the framework defaults ranges up to 115200 bits/sec.
The application can be used in two different paths for the communication using the framework, depending on the support available on the cellular modems. Some modules provide options to use the TCP/IP stack at the host end and other modules provide options to use the TCP/IP stack present on the cellular modem itself. In some cases, the cellular hardware module provides both. When the host TCP/IP stack (NetX) is used, the logical layers of NetX, the NSAL and the PPP are used as described in the architecture diagram. When the on‑chip stack is used, the socket APIs are used to communicate with the TCP/IP stack present on the cellular modem. However, the user cannot use both at the same time.
In the sf_cellular_qctlcatm1 framework, AT commands should be passed after the "APP RDY" string. However, in the current sf_cellular_qctlcatm1 framework, AT commands are being passed before the "APP RDY" string is received. There is no functional impact because, in the current sf_cellular_qctlcatm1 framework, instead of checking the "APP RDY" string, "OK" response is being checked in the BG 96 modem, which ensures that the modem is working.
As shown in the following control flow diagram, during the initialization using the configuration supplied by the user as required for the cellular modem, nx_ip_create is called. This API internally invokes the NSAL driver entry function that takes care of the link-level initialization and initializes the cellular hardware module. Additionally, it provisions the module and establishes the Network connection using the PPP interface.
During the provisioning of the cellular modem, control structure and user configuration structures are passed as arguments. The details of the user arguments used for provisioning are the authentication, APN, username and password.
The following flow diagram shows the flow for the on-chip stack path usage with the Cellular Socket interface.
The following flow diagram shows the sequence of steps that the packet transmission uses for the NetX application.
The following flow diagram shows the Packet reception for the Cellular Framework using NetX. In the case of a receive, when the data is received on the serial interface, the processing thread triggers the callback function and the callback functions handles the data and sends it to the NetX layers for further processing.
The Cellular Framework baud rate update feature works in the following stages:
The developer can configure the Baud rate of the UART under SF_CELLULAR in ISDE configuration as shown in the below image. This is the baud rate at which user wants the Modem to operate.
Operational Steps
When using the Cellular framework with NSAL, that is, with NetX/NetX Duo, the application should call the NetX nx_ip_delete() API directly.
When using the On chip networking stack, the application shouldcall the sf_cellular_api_t::close API from the BSD socket interface, which internally calls the Cellular framework module sf_cellular_api_t::close API.
The cellular framework provides provision to set the SIM Pin and PUK value of SIM as a ISDE XML properties to unlock the SIM Card. These properties are used by SF Cellular framework to unblock the SIM access if SIM is in Lock state. In addition to these properties, Cellular framework also provides a callback function property to read the SIM Pin and PUK value at runtime. If user sets this callback function, and Cellular framework founds that SIM is in Locked state (either SIM Pin or SIM PUK Lock) then Cellular framework calls the callback function with the SIM Lock status. Based on the Sim Lock status, user should provide SIM Pin and/or SIM PUK information to callback function as mentioned below:
Below is an illustrative code snippet for the callback function showing the configuration of the SIM Pin/PUK information at runtime.
To determine the current version of firmware on the module, issue the following commands:
To update (flash) the firmware for the Quectel BG96 (CAT M1, NB-IoT and GPRS), follow these instructions:
Unzip and install the LTE Driver on your PC, then connect the USB port of the module to the PC with a USB cable. Check if the DM port of USB appears in device manager:
Click Load FW Files and load the firmware path (shown as 1 in the figure below):
This section describes how to include the Cellular Framework module in an application using the SSP configurator.
To add the Cellular Framework module to an application, simply add it to a HAL /Common thread using the stacks selection sequence given in the following table. (The default name for the Cellular Framework module is g_sf_cellular0. This name can be changed in the associated Properties window.)
Cellular Framework Module Selection Sequence
| Resource | ISDE Tab | Stacks Selection Sequence |
|---|---|---|
| g_sf_cellular_socket0 BSD Socket using RYZ014 CATM1 / Quectel CATM1 On-Chip Stack on RYZ014 CATM1 / Quectel CATM1 Cellular Framework | Threads | New Stack> Framework> Networking> Cellular> BSD Socket using RYZ014 CATM1 / Quectel CATM1 On-Chip Stack on RYZ014 CATM1 / Quectel CATM1 Cellular Framework |
| g_sf_cellular_0 Cellular Framework on RYZ014 CATM1 / Quectel CATM1 Modem | Threads | New Stack> Framework> Networking> Cellular> Cellular Framework on RYZ014 CATM1 /Quectel CATM1 Modem |
| g_sf_el_nx0 NetX Port using Cellular Framework on sf_cellular_nsal_nx | Threads | New Stack> Framework> Networking> Cellular> NetX Port using Cellular Framework on sf_cellular_nsal_nx |
When the Cellular Framework module on sf_cellular is added to the thread stack as shown in the following figure, the configurator automatically adds any needed lower‑level modules. Any modules needing additional configuration information have the box text highlighted in Red. Modules with a Gray band are individual modules that stand alone. Modules with a Blue band are shared or common; they need only be added once and can be used by multiple stacks. Modules with a Pink band can require the selection of lower-level modules; these are either optional or recommended. (This is indicated in the block with the inclusion of this text.) If the addition of lower-level modules is required, the module description include Add in the text. Clicking on any Pink banded modules brings up the New icon and displays possible choices.
In the stack above, the Add SF Communications Framework block has not been populated yet. There are multiple possible selections for the Communication Framework; they are not all provided so as not to needlessly complicate the figure and the following configuration tables. Communications Framework on sf_uart_comms should be used when using the sf_cellular framework.
The Cellular Framework module must be configured by the user for the desired operation. The SSP configuration window will automatically identify (by highlighting the block in red) any required configuration selections, such as interrupts or operating modes, which must be configured for lower-level modules in order to ensure successful operation. Furthermore, only those properties that can be changed without causing conflicts are available for modification. Other properties are 'locked' and are not available for changes, and are identified with a lock icon for the 'locked' property in the Properties window in the ISDE. This approach simplifies the configuration process and makes it much less error-prone than previous 'manual' approaches to configuration. The available configuration settings and defaults for all the user-accessible properties are given in the Properties tab within the SSP configurator, and are shown in the following tables for easy reference.
Configuration Settings for the BSD Socket Using RYZ014 CATM1 On-Chip Stack on RYZ014 CATM1 Cellular Framework
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Enable or disable the parameter checking. |
| Name | g_sf_cellular_socket0 | Module name. |
Configuration Settings for the BSD Socket Using Quectel CATM1 On-Chip Stack on Quectel CATM1 Cellular Framework
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Enable or disable the parameter checking. |
| Name | g_sf_cellular_socket0 | Module name. |
| Name of generated initialization function | sf_cellular_qctcatm1_socket_init0 | Name of generated initialization function selection. |
| Auto Initialization | Enable, Disable Default: Enable | Auto initialization selection. |
Configuration Settings for the Cellular Framework on Quectel CATM1 Modem
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Enable or disable the parameter checking. |
| On-Chip Stack Support | Enabled, Disabled Default: Disabled | On-chip stack support selection. |
| AT Command Retry Count | 5 | Modem selection. |
| Name | g_sf_cellular0 | Module name. |
| SIM Pin (Used to Unlock SIM) | 1111 | SIM Pin selection. |
| SIM PUK Pin (Used to Unlock SIM) | 12345678 | SIM PUK Pin selection. |
| SIM Pin/PUK Callback to read SIM Pin/PUK value at runtimeNULL | NULL | SIM Pin/PUK read callback selection. |
| Number of Preferred Operator | 0 | Number of preferred operator selection. |
| Preferred Operator 1 Name | 40422 | Preferred operator 1 name selection. |
| Preferred Operator 1 Name Format | Long, Short, Numeric Default: Numeric | Preferred operator 1 name format selection. |
| Preferred Operator 2 Name | 40424 | Preferred operator 2 name selection. |
| Preferred Operator 2 Name Format | Long, Short, Numeric Default: Numeric | Preferred operator 2 name format selection. |
| Preferred Operator 3 Name | 40422 | Preferred operator 3 name selection. |
| Preferred Operator 3 Name Format | Long, Short, Numeric Default: Numeric | Preferred operator 3 name format selection. |
| Preferred Operator 4 Name | 40424 | Preferred operator 4 name selection. |
| Preferred Operator 4 Name Format | Long, Short, Numeric Default: Numeric | Preferred operator 4 name format selection. |
| Preferred Operator 5 Name | 40422 | Preferred operator 5 name selection. |
| Preferred Operator 5 Name Format | Long, Short, Numeric Default: Numeric | Preferred operator 5 name format selection. |
| Operator Select Mode | Auto, Manual, Deregister, Manual Fallback Default: Auto | Operator select mode selection. |
| Operator Name (Manual Mode Selection) | 40422 | Operator name selection. |
| Operator Name Format (Manual Mode Selection) | Long, Short, Numeric Default: Numeric | Operator name format selection. |
| Time Zone Update Policy | Enabled, Disabled Default: Enabled | Time zone update policy selection. |
| Receive Data Callback | sf_cellular_nsal_recv_callback | Receive data callback selection. |
| Provisioning Callback | celr_prov_callback | Provisioning callback selection. |
| Circular Queue Size in Bytes | 256 | Circular queue size selection. |
| SF Communications Framework Thread Stack Size | 512 | SF communications framework thread stack size selection. |
| Numerical priority of SF Communication Framework Thread. Legal values range from 0 through (TX_MAX_PRIORITIES-1), where a value of 0 represents the highest priority. | 5 | Numerical priority of SF communication framework thread selection. |
| Cellular Module Reset IO Pin | IOPORT_PORT_01_PIN_06 | Cellular module reset IO pin selection. |
| Network Scan Sequence | LTE cat.M1-> LTE Cat.NB1-> GSM, LTE Cat.M1-> GSM-> LTE Cat.NB1, GSM-> LTE Cat.NB1-> LTE Cat.M1, GSM-> LTE Cat.M1-> LTE Cat.NB1, LTE Cat.NB1 -> LTE Cat.M1 -> GSM, LTE Cat.NB1 -> GSM -> LTE Cat.M1 Default: LTE cat.M1-> LTE Cat.NB1-> GSM | Network scan sequence selection. |
Configuration Settings for the Cellular Framework on RYZ014 CATM1 Modem
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Enable or disable the parameter checking. |
| On-Chip Stack Support | Enabled, Disabled Default: Disabled | On-chip stack support selection. |
| AT Command Retry Count | 5 | Modem selection. |
| Name | g_sf_cellular0 | Module name. |
| SIM Pin (Used to Unlock SIM) | 1111 | SIM Pin selection. |
| SIM PUK Pin (Used to Unlock SIM) | 12345678 | SIM PUK Pin selection. |
| SIM Pin/PUK Callback to read SIM Pin/PUK value at runtimeNULL | NULL | SIM Pin/PUK read callback selection. |
| Number of Preferred Operator | 0 | Number of preferred operator selection. |
| Preferred Operator 1 Name | 40422 | Preferred operator 1 name selection. |
| Preferred Operator 1 Name Format | Long, Short, Numeric Default: Numeric | Preferred operator 1 name format selection. |
| Preferred Operator 2 Name | 40424 | Preferred operator 2 name selection. |
| Preferred Operator 2 Name Format | Long, Short, Numeric Default: Numeric | Preferred operator 2 name format selection. |
| Preferred Operator 3 Name | 40422 | Preferred operator 3 name selection. |
| Preferred Operator 3 Name Format | Long, Short, Numeric Default: Numeric | Preferred operator 3 name format selection. |
| Preferred Operator 4 Name | 40424 | Preferred operator 4 name selection. |
| Preferred Operator 4 Name Format | Long, Short, Numeric Default: Numeric | Preferred operator 4 name format selection. |
| Preferred Operator 5 Name | 40422 | Preferred operator 5 name selection. |
| Preferred Operator 5 Name Format | Long, Short, Numeric Default: Numeric | Preferred operator 5 name format selection. |
| Operator Select Mode | Auto, Manual Default: Auto | Operator select mode selection. |
| Operator Name (Manual Mode Selection) | 40422 | Operator name selection. |
| Operator Name Format (Manual Mode Selection) | Long, Short, Numeric Default: Numeric | Operator name format selection. |
| Time Zone Update Policy | Enabled, Disabled Default: Enabled | Time zone update policy selection. |
| Receive Data Callback | sf_cellular_nsal_recv_callback | Receive data callback selection. |
| Provisioning Callback | celr_prov_callback | Provisioning callback selection. |
| Circular Queue Size in Bytes | 256 | Circular queue size selection. |
| SF Communications Framework Thread Stack Size | 512 | SF communications framework thread stack size selection. |
| Numerical priority of SF Communication Framework Thread. Legal values range from 0 through (TX_MAX_PRIORITIES-1), where a value of 0 represents the highest priority. | 5 | Numerical priority of SF communication framework thread selection. |
| Cellular Module Reset IO Pin | IOPORT_PORT_04_PIN_14 | Cellular module reset IO pin selection. |
Configuration Settings for the Cellular Framework Common Instance
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Enable or disable the parameter checking. |
Typically, only a small number of settings must be modified from the default for lower-level drivers as indicated with red text in the thread stack block. Notice that some of the configuration properties must be set to a certain value for proper framework operation and will be locked to prevent user modification. The following tables identify all the settings within the properties section for the lower-level modules.
Configuration Settings for the NetX Port using the Cellular Framework on sf_cellular_nsal_nx
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Enable or disable the parameter checking. |
| Name | g_sf_el_nx0 | Module name. |
| PPP Stack Size in Bytes | 2048 | PPP stack size selection. |
| Name | g_nx_ppp0 | Module name. |
| Numerical priority of PPP Thread | 3 | Specify the PPP thread priority. The priority must be lower than IP Helper thread. Legal values range from 0 through (TX_MAX_PRIORITIES-1), where a value of 0 represents the highest priority. |
| Authentication Method | None, PAP, CHAP Default: None | Authentication method selection. |
| Invalid Packet Handler Callback | NULL | Invalid packet handler callback selection. |
| Link Down Callback | ppp_link_down_callback | Link down callback selection. |
| Link Up Callback | ppp_link_up_callback | Link up callback selection. |
| PAP Login Callback | NULL | A user callback function can be provided. |
| PAP Verify Login Callback | NULL | A user callback function can be provided. |
| Get Challenges Values Callback | NULL | A user callback function can be provided. |
| Get Responder Values Callback | NULL | A user callback function can be provided. |
| Get Verification Callback | NULL | A user callback function can be provided. |
| Local IPv4 Address (use commas for separation) | 0,0,0,0 | Local IPv4 address selection. |
| Peer IPv4 Address (use commas for separation) | 0,0,0,0 | Peer IPv4 address selection. |
Configuration Settings for the NetX PPP Common Instance
| ISDE Property | Value | Description |
|---|---|---|
| Name | g_nx_ppp_common0 | Module name. |
Configuration Settings for the NetX Packet Pool Instance
| ISDE Property | Value | Description |
|---|---|---|
| Name | g_packet_pool0 | Module name. |
| Packet Size (bytes) | 1568 | Packet size selection. |
| Number of Packets in Pool | 16 | Number of packets in pool selection. |
| Name of generated initialization function | packet_pool_init0 | Name of generated initialization function selection. |
| Auto initialization | Enable, Disable Default: Enable | Auto initialization selection. |
Configuration Settings for the NetX Common on nx Instance
| ISDE Property | Value | Description |
|---|---|---|
| Name of generated initialization function | nx_common_init0 | Name of generated initialization function selection. |
| Auto initialization | Enable, Disable Default: Enable | Auto initialization selection. |
HTTP file download of up to 2 MB is tested on BG96. Following is the list of ISDE properties that must be updated for downloading of files over HTTP while using Cellular framework.
ISDE configuration parameters for HTTP download using BG96 RevF module
| ISDE Property | Value | Description |
|---|---|---|
| Packet Size of NetX packet pool instance (bytes) | 1568 Default: 1568 | Packet size selection. |
| Number of Packets in Pool for NetX packet pool instance | 64 Default:16 | Number of packets in pool selection. |
| IP thread priority | 2 Default: 3 | Thread priority of IP helper thread for NetX IP instance. |
| Numerical priority of SF Communication Framework thread | 3 Default: 5 | Priority value of SF Comms thread in g_sf_cellular block. |
| TCP socket Window Size | 16384 (for GSM network 8192) Default: 1024 | TCP socket window size of g_http_client. |
ISDE configuration parameters for HTTP download using RYZ014 module
| ISDE Property | Value | Description |
|---|---|---|
| Packet Size of NetX packet pool instance (bytes) | 1568 Default: 1568 | Packet size selection. |
| Number of Packets in Pool for NetX packet pool instance | 64 Default:16 | Number of packets in pool selection. |
| IP thread priority | 2 Default: 3 | Thread priority of IP helper thread for NetX IP instance. |
| Numerical priority of SF Communication Framework thread | 3 Default: 5 | Priority value of SF Comms thread in g_sf_cellular block. |
| TCP socket Window Size | 16384 Default: 1024 | TCP socket window size of g_http_client. |
The Cellular Framework module uses the clocks required for the specific selections of the lower-level modules.
The Cellular Framework module uses input and output pins depending on the selections of the lower-level modules.
In a typical Cellular application, much of the work is done by SSP based on the configured cellular module stack. When the IP instance along with the Cellular framework is added using the configurator, it includes the PPP stack as part of the framework. In addition, it also includes the NSAL and cellular device driver code. The auto-generated code is responsible for cellular initialization.
The user added code is responsible for the data connections and the ICMP ping. It is responsible for sending the ping request to the user entered Public IP address and for verifying the ping response. Callback functions can be implemented for PPP link down, PPP link up and cellular provisioning.
The steps in using the Cellular Framework in a typical application are:
nx_ip_status_check API.nx_icmp_ping API.nx_event_flags_set API.The following figure illustrates common steps in a typical operational flow diagram:
