Synergy Software Package User's Manual
Wi-Fi QCA4010 Framework

Wi-Fi QCA4010 Framework Introduction

The SX-ULPGN is a low-power, compact IEEE 802.11b/g/n 2.4GHz 1x1 Wireless LAN module equipped with the Qualcomm® QCA4010 Wireless SOC. 

The Wi-Fi QCA4010 framework provides a high-level API for configuring and provisioning Silex QCA4010 ULPGN module as well as perform TCP and UDP data transfers with on-chip networking capability.

Wi-Fi QCA4010 Framework Module Features

  • Provides high-level APIs to configure and provision a SX-ULPGN Wi-Fi module.
  • Provides three different implementations for: 
    • A Wi-Fi device driver stack using the sf_wifi_qca4010 framework. 
    • An on-chip stack using the sf_wifi_qca4010_onchip_stack framework.
    • A socket stack using the sf_wifi_qca4010_socket framework.
  • Provides a socket interface to create socket-based applications with the On-chip TCP/UDP.
wifi_qca4010_BD.png
Wi-Fi QCA4010 Framework Module Block Diagram
Note
 The On-Chip Stack on qca4010 Wi-Fi Framework, qca4010 Wi-Fi Device Driver  on sf_wifi_qca4010 can be used as a lower-level implementation of the Socket Framework or on its own.

SF WIFI QCA4010 Framework APIs Overview

The QCA4010 Wi-Fi Framework provides APIs for features such as scanning, provisioning with access points, initialization of access point with different security types (WPA2, WPA, WEP, Open), enabling/disabling DHCP server in AP mode, sending AT commands directly to wifi module and obtain the response, creation of TCP and UDP sockets, TCP and UDP data transfers. 

Complete list of the available APIs, an example API call and a short description of each can be found in the following table. A table of status return values follows the API summary table. 

Wi-Fi QCA4010 APIs

Wi-Fi QCA4010 APIs

API Name Example API call and description
open g_sf_wifi_qca4010.p_api->open(g_sf_wifi_qca4010.p_ctrl, g_sf_wifi_qca4010.p_cfg);
Open lower level driver of Wi-Fi framework.
close g_sf_wifi_qca4010.p_api->close(g_sf_wifi_qca4010.p_ctrl);
Close lower level driver of Wi-Fi framework.
provisioningSet g_sf_wifi_qca4010.p_api->provisioningSet(g_sf_wifi_qca4010.p_ctrl, &provisioning_info);
Provision/Connect to Access Point or Initiate an access point with information provided by user such as mode (AP/station), channel, SSID, security type (WPA2/WPA/WEP/Open), WEP key index, encryption type(TKIP/CCMP), passphrase/key.
wifiStatusGet g_sf_wifi_qca4010.p_api->wifiStatusGet(g_sf_wifi_qca4010.p_ctrl, &wifi_status);
Get the status of connected or Initiated Access Point.
scan g_sf_wifi_qca4010.p_api->scan(g_sf_wifi_qca4010.p_ctrl, scan_result, scan_count);
San for available access points.
versionGet g_sf_wifi_qca4010.p_api->versionGet(&version);
Get the version based on compile time macros.
CommandSend g_sf_wifi_qca4010.p_api->CommandSend(g_sf_wifi_qca4010.p_ctrl, &cmd, &resp, timeout);
Send AT command directly to Wifi module and obtain the response.
Note
For more complete descriptions of operation and definitions for the function data structures, typedefs, defines, API data, API structures and function variables, review the SSP User's Manual API References for the associated module.
For provisioningSet API, user has to provide information about the access point such as SSID, security type, Key(Password), encryption type, channel and mode. SSID and passphrase cannot contain commas. This is a current limitation of Silex module firmware.

Wi-Fi QCA4010 On chip Stack APIs

Wi-Fi QCA4010 On chip Stack APIs

API Name Example API call and description
open g_sf_wifi_qca4010_onchip_stack.p_api->open(g_sf_wifi_qca4010_onchip_stack.p_ctrl, g_sf_wifi_qca4010_onchip_stack.p_cfg);
Open on-chip stack layer of Wi-Fi framework.
close g_sf_wifi_qca4010_onchip_stack.p_api->close(g_sf_wifi_qca4010_onchip_stack.p_ctrl);
Close on-chip stack layer of Wi-Fi framework.
ipAddressCfg g_sf_wifi_qca4010_onchip_stack.p_api->ipAddressCfg(g_sf_wifi_qca4010_onchip_stack.p_ctrl, &ip_cfg);
Set static IP or Enable DHCP based on user input.
ping g_sf_wifi_qca4010_onchip_stack.p_api->ping(g_sf_wifi_qca4010_onchip_stack.p_ctrl, &ping_ip,0, 0);
Ping the IP address provided by the user.
versionGet g_sf_wifi_qca4010_onchip_stack.p_api->versionGet(&version);
Get the version based on compile time macros.
dhcpServerStart   g_sf_wifi_qca4010_onchip_stack.p_api->dhcpServerStart (g_sf_wifi_qca4010_onchip_stack.p_ctrl, &start_ip, &end_ip)
Start DHCP server in AP mode.
dhcpServerStop g_sf_wifi_qca4010_onchip_stack.p_api->dhcpServerStop(g_sf_wifi_qca4010_onchip_stack.p_ctrl, &start_ip, &end_ip)
Stop DHCP server in AP mode.
Note
For more complete descriptions of operation and definitions for the function data structures, typedefs, defines, API data, API structures and function variables, review the SSP User's Manual API References for the associated module.
DHCP server has to be used in AP mode and not recommended to be used with station mode. User must set a fixed/static IP address to the AP using the API 'ipAddressCfg' and then start DHCP server.

Wi-Fi QCA4010 Socket APIs

Wi-Fi QCA4010 Socket APIs

API Name  Example API call and description 
open   g_sf_wifi_qca4010_socket.p_api->open(g_sf_wifi_qca4010_socket.p_ctrl, g_sf_wifi_qca4010_socket.p_cfg); 
Open Socket layer of Wi-Fi Framework. 
close   g_sf_wifi_qca4010_socket.p_api->close(g_sf_wifi_qca4010_socket.p_ctrl); 
Close Socket layer of Wi-Fi Framework. 
versionGet   g_sf_wifi_qca4010_socket.p_api->versionGet(&version); 
Get the version based on compile time macros. 
socketCreate   g_sf_wifi_qca4010_socket.p_api->socketCreate(g_sf_wifi_qca4010_socket.p_ctrl, 0, SOCK_STREAM, AF_INET); 
Create TCP/UDP socket 
socketConnect   g_sf_wifi_qca4010_socket.p_api->socketConnect(g_sf_wifi_qca4010_socket.p_ctrl, 0, (structsockaddr*)&sock_addr,addrlen); 
Connect TCP/UDP client to Server. 
socketDisconnect   g_sf_wifi_qca4010_socket.p_api->socketDisconnect(g_sf_wifi_qca4010_socket.p_ctrl, 0); 
Disconnect socket connection and close the network. 
socketSend   g_sf_wifi_qca4010_socket.p_api->socketSend(g_sf_wifi_qca4010_socket.p_ctrl, 0, (uint8_t*)&data, length, 1000); 
Send data from TCP/UDP socket. 
socketRecv   g_sf_wifi_qca4010_socket.p_api->socketRecv(g_sf_wifi_qca4010_socket.p_ctrl, 0, (uint8_t*)&data, 1024, 1000); 
Receive datafromTCP/UDPserver. 
socketStatusGet   g_sf_wifi_qca4010_socket.p_api->socketStatusGet(g_sf_wifi_qca4010_socket.p_ctrl, 0, (uint32_t *)&socket_status); 
Check the status of socket created. 
Note
 For more complete descriptions of operation and definitions for the function data structures, typedefs, defines, API data, API structures and function variables, review the SSP User's Manual API References for the associated module. 
For socketCreate  API, user has to pass parameter to select TCP or UDP socket, family (IPV4). The parameter socket number should be '0' for single socket and while creating multiple sockets, socket number of first socket has to be '0' and increments by 1 for the next socket.
For socketConnect API, user has to pass Server IP address, family (IPV4), Port number

Wi-Fi QCA4010 Framework Status Return Values

Wi-Fi QCA4010 Status Return Values

            Name  Description 
SSP_SUCCESS  API call successful. 
SSP_ERR_INVALID_ARGUMENT  Parameter has invalid value. 
SSP_ERR_WIFI_FAILED  API call not successful. 
SSP_ERR_ASSERTION  An input pointer is Null 
SSP_ERR_ALREADY_OPEN  Unit is already opened 
SSP_ERR_WIFI_INIT_FAILED  Driver initialization failed. 
SSP_ERR_IN_USE  Module is already in use 
SSP_ERR_NOT_OPEN  Unit is not open 
SSP_ERR_INTERNAL  Internal error occurred 
SSP_ERR_TIMEOUT Timeout error
SSP_ERR_UNSUPPORTED Functionality (IPV6) not supported
Note
Lower-level drivers may return common error codes. Refer to the SSP User's Manual API References for the associated module for a definition of all relevant status return values. 

SF_WIFI_QCA4010 Framework Module Operational Overview

The Wi-Fi framework provides a high-level interface for the application to configure the Wi-Fi module, provision the Wi-Fi module in station or AP mode with different security types and perform TCP/UDP data transfers in server and client mode.

The following figure provides an overview of the QCA4010 Wi-Fi framework layered architecture.

wifi_qca4010_SI.png
Wi-Fi QCA4010 Framework Module Stack Implementation
  • Socket stack using the sf_wifi_qca4010_socket framework provides APIs to create, connect TCP/UDP sockets and perform data send and receive operations in client/server mode.
  • On-chip stack using the sf_wifi_qca4010_onchip_stack framework provides APIs to configure static IP or enable DHCP, ping, Enable/Disable DHCP server.
  • Wi-Fi device driver stack using the sf_wifi_qca4010 framework provides APIs to initialize Wifi module, provision the module in station or AP mode, scan for available access points, get the status of connected or initiated access point, send AT commands directly to Wifi module.
Note
 The On-Chip Stack on qca4010 Wi-Fi Framework, qca4010 Wi-Fi Device Driver  on sf_wifi_qca4010 can be used as a lower-level implementation of the Socket Framework or on its own.

SF_WIFI_QCA4010 Framework Module Important Operational notes and Limitations

SF_WIFI_QCA4010 Framework Module Operational Notes

Operational Overview 

SF_WIFI_QCA4010 Framework is used to: 

  1. Scan available access points.
  2. Provision/connect to the desired access point with the information provided by user such as SSID, security type, Key, encryption type, WEP key index, channel, Mode.
  3. Initiate an access point with different security types (WPA2/WPA/WEP/Open).
  4. Enable/Disable DHCP server in AP mode.
  5. Obtain the status of connected access point or initiated AP such as SSID, Phy Mode, MAC Address, Mode, Channel. 
  6. Set a static IP or enable DHCP and obtain information such as IP Address, NetMask and Gateway of the Wifi Module. 
  7. Ping the server IP address. 
  8. Send custom AT commands directly to wifi module and obtain the response.
  9. Create single/multiple TCP/UDP sockets. 
  10. Connect TCP/UDP client to the server and vice-versa.
  11. Obtain the current socket status. 
  12. Send or receive data from TCP/UDP server/client. 
  13. Disconnect the socket and close the connection. 
Note
Wi-Fi framework supports 1 or 2 UARTs for interfacing with the SX-ULPGN module. The second UART is considered optional for single socket and is mandatory for multiple socket operation.
The number of sockets that can be created is based on the memory availability of board. 
SX-ULPGN supports WEP security with WEP key as 10 or 26 digit hexadecimal string.

SF_WIFI_QCA4010 Framework Module limitations

Wi-Fi QCA4010 Framework limitations 

1. The Wi-Fi Framework does not support the Synergy S1 board series due to memory constraints. 

2. Only IPV4 protocol version is supported as majority of the Silex AT commands does not support IPV6.

  1. The SX-ULPGN chip does not support ethernet pass through. Hence NetX stack and related services are not supported. Only on-chip stack and related APIs are supported. 

4. WPS (PUSH/PIN) method of station provisioning is not supported.

SX-ULPGN Hardware limitations:

1. SX-ULPGN chip doesn't support ethernet pass through. 

2. WPA 2 Enterprise is not supported by SX-ULPGN. 

3. SX-ULPGN supports only 2.4GHz frequency band, 5GHz band is not supported. 

Including the SF_WIFI_QCA4010 Framework in an Application

This section describes how to include SF_WIFI_QCA4010 framework in an application using the SSP configurator. 

Note
This section assumes you are familiar with creating a project, adding threads, adding a stack to a thread and configuring a block within the stack. If you are unfamiliar with any of these items, refer to the first few chapters of the SSP User's Manual to learn how to manage each of these important steps in creating SSP-based applications. 

To add the sf_wifi_qca4010 Framework module to an application, simply add it to a thread using the stacks selection sequence given in the following table. (The default name for the Wi-Fi QCA4010 Framework module is g_sf_wifi_qca4010_socket. This name can be changed in the associated Properties window.) 

Wi-Fi QCA4010 Framework Module Selection Sequence

Resource  ISDE tab  Stack selection sequence 
g_sf_wifi_qca4010_socket Socket using qca4010 On-Chip Stack on qca4010 Wi-Fi Framework  Threads  New Stack> Framework> Networking> Wi-Fi>Socket using qca4010 On-Chip Stack on qca4010 Wi-Fi Framework 
g_sf_wifi_qca4010_onchip_stack On-Chip Stack on qca4010 Wi-Fi Framework  Threads  New Stack> Framework> Networking> Wi-Fi>On-Chip Stack on qca4010 Wi-Framework 
g_sf_wifi_qca4010 qca4010 Wi-Fi Device Driver on sf_wifi_qca4010  Threads  New Stack> Framework> Networking> Wi-Fi>qca4010 Wi-Fi Device Driver on sf_wifi_qca4010 

When the SF_WIFI_QCA4010 Framework is added to the thread stack as shown in the above figure, the configurator automatically adds any needed lower-level module. Any modules needing additional configuration information have the box text highlighted in Red (Here additional UART driver has to be added by the user for multiple socket operations). 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. 

wifi_qca4010_MS.png

Configuring the Wi-Fi QCA4010 Framework

The Wi-Fi QCA4010 must be configured by the user for the desired operation. 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. Only properties that can be changed without causing conflicts are available for modification. Other properties are locked and 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. 

Note
You may want to open your ISDE, create the module and explore the property settings in parallel with looking over the following configuration table settings. This will help orient you and can be a useful 'hands-on' approach to learning the ins and outs of developing with SSP. 

Configuration Settings for g_sf_socket0 on qca4010 Wi-Fi Framework

ISDE Property  Value  Description 
Parameter checking  BSP, Enabled, Disabled 
Default: BSP 
Selects if code for parameter  
checking is to be included in  
the build.
Number of supported socket instances  1 – 12
Default :1 
Number of sockets to be created.
Name  g_sf_socket0  Name of upper level framework layer.
Name of generated initialization function  sf_socket_init0  Name of auto generated function. 
Auto Initialization  Enable, Disable 
Default: Enable 
Selects if code for auto-initialization to be included in the build. 

Configuration Settings for g_sf_wifi_onchip_stack0 on Wi-Fi Framework

ISDE Property  Value  Description 
Parameter Checking   BSP, Enabled, Disabled 
Default: BSP 
Selects if code for parameter  
checking is to be included in  
the build.
Name  g_sf_wifi_onchip_stack0  Name of on-chip stack layer. 

Configuration Settings for g_sf_wifi_qca40100 on qca4010 Wi-Fi Framework

ISDE Property  Value  Description 
Parameter Checking  BSP, Enabled, Disabled 
Default: BSP 
Selects if code for parameter  
checking is to be included in  
the build. 
AT command Retry count  5 – 255 
Default: 10 
Number of retries of issuing AT command in case of failure in response. 
Hardware Mode  802.11b, 802.11g, 802.11n 
Default: 802.11n 
Hardware mode of Wi-Fi Module. 
Reset Pin   Default: IOPORT_PORT_10_PIN_05  Wi-Fi module reset IO pin selection. 
Queue size in bytes  256 - 512
Default: 256 
UART reception queue size.
Response Buffer size  256 - 4096
Default: 2048 
Response Buffer size selection. 
Note
The example values and defaults are for a project using the Synergy S7G2 MCU Family. Other MCUs may have different default values and available configuration settings. 

Configuring the Wi-Fi QCA4010 Framework Lower-Level Modules

Typically, only a small number of settings must be modified from the default for lower-level drivers. 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 r_sci_uart driver

ISDE Property  Value  Description 
External RTS Operation  Disable, Enable 
Default: Disable 
Enable an IOPORT pin to be used as RTS signal. For RTS functionality, set this configuration parameter to Enable and specify the configuration Name of UART callback function for the RTS external pin control. 
Reception  Enable, Disable
Default: Enable 
Enable or disable UART reception for all UART channels on SCI. Setting this configuration parameter to Disable reduces code size because the portion of code for UART reception is not compiled. You cannot set this parameter for individual UART channels. 
Transmission  Enable, Disable
Default: Enable 
Enable or disable UART transmission for all UART channels on SCI. Setting this configuration to Disable reduces code size because the portion of code for UART transmission is not compiled. However, you can only set this configuration to Disable if no other SCI channels which work as UART ports are transmitting. 
Parameter checking  BSP, Enabled, Disabled
Default: BSP 
Enable or disable parameter error checking. 
Name  g_uart0  The name to be used for UART on SCI module control block instance. This name is also used as the prefix of the other variable instances. 
Channel  0-9 
Default : 0
SCI channel number. 
Baud rate  Default : 9600 Baud rate selection. 
Data bits  7 bits, 8, bits, 9 bits
Default: 8 bits 
UART data bits. 
Parity  None, Odd, Even
Default: None 
UART parity bits. 
Stop bits  1 bit, 2 bits
Default: 1 bit 
UART stop bits. 
CTS/RTS selection  CTS (Note that RTS is available when enabling External RTS Operation mode which uses 1 GPIO pin), RTS (CTS is disabled) Default: RTS (CTS is disabled)  Select CTS or RTS for the CTSn/RTSn pin of SCI channel n. The SCI hardware supports either the CTS or the RTS control signal on this pin but not both. For an application that uses both CTS and RTS, select CTS for this configuration parameter and enable the configuration External RTS Operation specifying the configuration Name of UART callback function for the RTS external pin control. 
Name of UART callback function  sf_wifi_qca4010_serial_uart_callback  UART callback to receive data/AT command response.
Name of UART callback function for the RTS external pin control to be defined by the user  NULL  Name must be a valid C symbol. 
Clock Source  Internal Clock, External Clock 8x baudrate, External Clock 16x baudrate 
Default: Internal Clock 
Selection of the clock source to be used in the baud-rate clock generator block. 
Baudrate Clock Output from SCK pin  Enable, Disable
Default: Disable 
Optional setting to output the baud-rate clock on the SCKn pin for the selected channel n. 
Start bit detection  Falling Edge, Low Level
Default: Falling Edge 
Start bit detection mode in the reception, usually set Falling Edge to this configuration. 
Noise Cancel  Enable, Disable
Default: Disable 
Enable the digital noise cancellation on RXDn pin. The digital noise filter block in SCI consists of two-stage flip-flop circuits. For details, refer to the Noise cancellation section in the Renesas Synergy hardware manual. 
Bit Rate Modulation Enable  Enable, Disable
Default: Enable 
Bit rate modulation enable selection 
Receive Interrupt 
Priority 
Priority 0 (highest), Priority 1:2, Priority 3 (CM4: valid, CM0+: lowest- not valid if using ThreadX), Priority 4:14 (CM4: valid, CM0+: invalid), Priority 15 (CM4 lowest - not valid if using ThreadX, CM0+: invalid) Default: Disabled  Receive interrupt priority selection. 
Transmit Interrupt Priority  Priority 0 (highest), Priority 1:2, Priority 3 (CM4: valid, CM0+: lowest- not valid if using ThreadX), Priority 4:14 (CM4: valid, CM0+: invalid), Priority 15 (CM4 lowest - not valid if using ThreadX, CM0+: invalid) 
Default: Disabled 
Transmit interrupt priority selection. 
Transmit End Interrupt Priority  Priority 0 (highest), Priority 1:2, Priority 3 (CM4: valid, CM0+: lowest- not valid if using ThreadX), Priority 4:14 (CM4: valid, CM0+: invalid), Priority 15 (CM4 lowest - not valid if using ThreadX, CM0+: invalid) Default: Disabled  Transmit end interrupt priority selection. 
Error Interrupt Priority  Priority 0 (highest), Priority 1:2, Priority 3 (CM4: valid, CM0+: lowest- not valid if using ThreadX), Priority 4:14 (CM4: valid, CM0+: invalid), Priority 15 (CM4 lowest - not valid if using ThreadX, CM0+: invalid) Default: Disabled  Error interrupt priority selection. 
Baud rate Percent Error  Value must be greater than 0.0 and less than 15.0
Default; 2.0 
Maximum baud rate percent error allowed in order for the module to function 
UART Communication Mode  RS232, RS485
Default: RS232 
UART communication mode selection, usually it is RS232 mode 
UART RS485 Communication Mode  Half Duplex, Full Duplex
Default: Half duplex 
UART RS485 communication mode selection as half duplex or full duplex 
RS485 DE Port  00 to 11
Default: 09 
Select the port number of Driver Enable Pin 
RS485 DE Pin  00 to 15
Default: 14 
Select the pin number of Driver Enable Pin 
Note
Additional UART is mandatory for multiple socket operation and is optional for single socket operation. 

Configuration of second UART driver instance is same as first UART instance which is described above. 

Note
 The example settings and defaults are for a project using the Synergy S7G2 MCU Group. Other MCUs may have different default values and available configuration settings. 

Configuration for the Transfer Driver on r_dtc Event SCI0 TXI

ISDE   Property  Value Description 
Parameter Checking  Enabled, Disabled
Default: Disabled 
Selects if code for parameter checking is to be included in the build 
Software Start  Enabled, Disabled
Default: Disabled 
Set start mode 
Linker section to keep DTC vector table  .ssp_dtc_vector_table  Linker section setting 
Name  g_transfer0  Module name 
Mode  Normal  Mode selection 
Transfer Size  1 Bytes  Transfer size selection 
Destination Address Mode  Fixed  Destination address mode selection 
Source Address Mode  Incremented  Source address mode selection 
Repeat Area (Unused in Normal Mode)  Source   Repeat area selection 
Interrupt Frequency  After all transfers have completed  Interrupt frequency selection 
Destination Pointer  NULL  Destination pointer selection 
Source Pointer  NULL  Source pointer selection 
Number of Transfers  Number of transfers selection 
Number of Blocks (Valid only in Block Mode)  Number of blocks selection 
Activation Source (Must enable IRQ)  Event SCI0 TXI  Activation source selection 
Auto Enable  True, False Default: True  Auto enable selection 
Callback (Only valid with Software start)  NULL  Callback selection 
ELC Software Event Interrupt Priority  Priority 0 (highest), Priority 1:2, Priority 3 (CM4: valid, CM0+: lowest- not valid if using ThreadX), Priority 4:14 (CM4: valid, CM0+: invalid), Priority 15 (CM4 lowest - not valid if using ThreadX, CM0+: invalid)
Default: Disabled 
ELC Software Event interrupt priority selection 

Addition of DTC driver for reception is not recommended. 

Note
The example values and defaults are for a project using the Synergy S7G2 MCU Family. Other MCUs may have different default values and available configuration settings. 

SF_WIFI_QCA4010 Framework Module Clock configuration

SF_WIFI_QCA4010 Framework has no specific clock configuration requirements.

SF_WIFI_QCA4010 Framework Module pin configuration

The SF_WIFI_QCA4010 Framework module uses input and output pins of the lower level UART driver.

Using the Wi-Fi QCA4010 Framework Module in an Application

Wi-Fi framework can be used to initialize access point (AP mode) or connect client to AP/router (station mode)

The typical steps of using the Wi-Fi Framework in an application for station mode are:

  1. Initialize the Wi-Fi module using sf_wifi_qca4010_socket_api_t::open API.
  2. Scan for the available access points using sf_wifi_qca4010_api_t::scan API.
  3. Connect to the desired access point using sf_wifi_qca4010_api_t::provisioningSet API. User has to provide the information such as SSID, security type (WPA2/WPA/WEP/Open), Key, Mode, Channel, encryption type, WEP key index of the access point to be connected.
  4. After connection is successful, obtain the status of the connected AP using sf_wifi_qca4010_api_t::wifiStatusGet API.
  5. Configure IP address(static or Dynamic) using sf_wifi_qca4010_onchip_stack_api_t::ipAddressCfg API.
  6. Ping the server IP using sf_wifi_qca4010_onchip_stack_api_t::ping API.
  7. After ping is successful, create and connect single/multiple TCP/UDP sockets in client or server mode using sf_wifi_qca4010_socket_api_t::socketCreate and sf_wifi_qca4010_socket_api_t::socketConnect API’s.
  8. Send data from TCP/UDP client to server using sf_wifi_qca4010_socket_api_t::socketSend API.
  9. Receive data from TCP/UDP server using sf_wifi_qca4010_socket_api_t::socketRecv API.
  10. Disconnect single/multiple sockets using sf_wifi_qca4010_socket_api_t::socketDisconnect API to close the network connection.
  11. De-Initialize the Wi-Fi module using sf_wifi_qca4010_socket_api_t::close API.

The typical steps of using the Wi-Fi Framework in an application for AP mode are:

  1. Initialize the Wi-Fi module using sf_wifi_qca4010_socket_api_t::open API.
  2. Initialize/provision access point using sf_wifi_qca4010_api_t::provisioningSet API. User has to provide the information such as SSID, security type (WPA2/WPA/WEP/Open), Key, Mode, Channel, encryption type, WEP key index to the access point.
  3. Set a static IP address using sf_wifi_qca4010_onchip_stack_api_t::ipAddressCfg API.
  4. Enable DHCP server using sf_wifi_qca4010_onchip_stack_api_t::dhcpServerStart API by specifying start and end IP address.
  5. Once the above mentioned steps are successful, client can connect to the initiated access point and obtain the IP address in between the range set by DHCP server of AP.
  6. After connection is successful, user can perform operations such as ping, TCP/UDP data transfers.
Note
SX-ULPGN supports WEP security with either 10 or 26 digit hexadecimal string.