![]() |
Synergy Software Package User's Manual
|
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.
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
| 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. |
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. |
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. |
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 |
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.
Operational Overview
SF_WIFI_QCA4010 Framework is used to:
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.
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.
This section describes how to include SF_WIFI_QCA4010 framework in an application using the SSP configurator.
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.
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.
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. |
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 |
Configuration of second UART driver instance is same as first UART instance which is described above.
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 | 0 | Number of transfers selection |
| Number of Blocks (Valid only in Block Mode) | 0 | 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.
SF_WIFI_QCA4010 Framework has no specific clock configuration requirements.
The SF_WIFI_QCA4010 Framework module uses input and output pins of the lower level UART driver.
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:
The typical steps of using the Wi-Fi Framework in an application for AP mode are: