To debug using the Ozone IDE, please follow the instructions below.

Prior to debugging, please make sure you flash the firmware, that you wish to debug, using Simplicity Commander.
Link to flash the firmware: https://docs.silabs.com/wiseconnect/latest/wiseconnect-getting-started/getting-started-with-soc-mode#upgrade-si-wx91x-connectivity-firmware

Settings:

1. Install Ozone using this link: https://www.segger.com/downloads/jlink/#Ozone
2. Download "sl_siw917.jdebug" and "SiWx917.svd" files from this given link: https://www.silabs.com/Wi-Fi_I&C_Apps/Ozone/Ozone.zip
3. Unzip the downloaded folder.
4. Settings in"sl_siw917.jdebug" file should be done appropriately as mentioned below:
   

Where, 
Project.AddPathSubstitute ("C:\Users\SimplicityStudio\workspace\wifi_powersave_standby_associated_soc", "$(ProjectDir)");  // Please provide the path of the folder.

Project.SetHostIF ("USB", "440270093");                       // Check for this number using Simplicity Commander as shown in the below image:

Project.AddSvdFile ("C:\Users\Downloads\SiWx917.svd");   // Use the SVD file: SiWx917.svd

File.Open ("C:\Users\Downloads\wifi_powersave_standby_associated_soc.axf");   // Optional to add the *.axf file.

1. Connect your board and make sure it is in "MCU" Debug mode in Simplicity Commander.
    
2. Open Ozone IDE and click on "Next" button on the popup as shown below:  
   
    
3. Now in Emulators connected via USB section, select your board and click on "Next" button.
   
    
4. Either click on "Next" Button or Browse the *.axf file. This is optional step.
   
    
5. Keep the default settings as is, in "Optional Settings" and click on "Finish" button.
   
    
6. Make the changes as shown below in "Project Load Diagnostics" and click on "Continue" button.
   
    
7. Now Click on "File" section and select "Open" option:
   
    
8. Now browse the "sl_siw917.jdebug" file and select it. 
   
    
9. Another popup would automatically be prompted, browse and select the *.axf file for debugging
   
    
10. Click on "Attach & Halt Program"
     
    
     
11. Click on "Reset & Break at Symbol"  
    
    
    
     
12. After the 11th Step, the pointer will be at main() function:

     

Above are the steps which can help one to debug SiW917 using Ozone IDE.


 

Would you like to integrate a new sensor?

One can add more sensors to the Sensor Hub by following the instructions in this section. For adding new sensors, the below layers play a critical role.

• HUB HAL Interface Layer: The HUB HAL Interface Layer serves as an interface between the Sensor Hub Service Layer and the Sensors HAL Layer. It handles the communication between the high-level services and the low-level sensor hardware abstraction.

• Sensors HAL Layer: The Sensors HAL Layer abstracts the hardware-specific details of the sensors. It communicates with the Sensor Driver Layer to facilitate sensor-specific operations.

• Sensor Driver Layer: The Sensor Driver Layer is responsible for interacting with individual sensors. It communicates with the Sensors HAL Layer to abstract the underlying hardware complexities and provides a standardized interface for the Sensors HAL Layer.

• Peripheral Drivers Layer: The Peripheral Drivers Layer is responsible for managing communication with the physical peripherals connected to the sensors. This layer ensures that the sensor drivers can interact seamlessly with the underlying hardware.

• Step 1:
  Individual sensor files should be created, user needs to create 4 files that should be integrated with the Sensor Hub, which are the sensorHal.c, sensorHal.h, sensor.c, and sensor.h.

  • sensorHal.c: This example file uses simple communication APIs between the HUB HAL interface layer and any sensor HAL APIs. Users can refer to sensors/src/light_sensor/lightsensor_hal.c file and can create a similar file.
  • sensor.c This example file uses simple communication APIs for transferring any sensor data through the I2C/ SPI/ ADC interface. The User should refer Sensor datasheet for sensor driver implementations. Users can refer to sensors/src/light_sensor/bh170fvi.c file and can create a similar file.

• Step 2:
  HUB HAL Interface will become the communication path between the sensor Hub service layer and the Sensor HAL layer. Users should map the sensor HAL APIs in sl_sensor_impl_type_t structure, which is present in *\sensors\src\hub_hal_intf.c file.
  For Example,

  sl_sensor_impl_type_t sensor_impls[] = {
  
  #ifdef SL_CONFIG_SENSOR_LIGHT //Light sensor operations
  {
  .type    = SL_LIGHT_SENSOR_ID,
  .create  = sl_si91x_lightsensor_create,
  .delete  = sl_si91x_lightsensor_delete,
  .sample  = sl_si91x_lightsensor_sample,
  .control = sl_si91x_lightsensor_control,
  },
  

  • Where the above members of the structure state,
    • type is the type of the sensor.
    • create is a function pointer to API which creates an instance of the respective sensor
    • delete is a function pointer to API which deletes the respective sensor
    • sample is a function pointer to API which samples and collects the data for the respective sensor
    • control is a function pointer to API which gives the commands to the respective sensor

• After mapping the APIs in the HUB HAL interface, sensor types and sensor IDs must be generated, which should be updated in the *sensors_config.h file. Please carry out the configuration using the instructions below.

• Step 3:
  Now add all the sensor IDs in sl_sensor_id_t* structure, which is present in /sensors/inc/sensors_config.h, to create a unique sensor ID which Sensor Hub Application will use further operations on Sensors.
  For Example,

  typedef enum {
  #ifdef SL_CONFIG_SENSOR_LIGHT
  SL_SENSOR_BH1750_ID = (SL_LIGHT_SENSOR_ID << SL_SENSOR_ID_OFFSET) | SL_BH1750_ID, ///< Bh1750 sensor id
  #endif
  } sl_sensor_id_t;

  • where SL_LIGHT_SENSOR_ID is the Sensor type which should be added to the sl_sensor_type_t structure

  • where SL_SENSOR_ID_OFFSET is the Sensor offset ID

  • where SL_BH1750_ID is here individual sensor ID (light sensor ID)

  • where SL_SENSOR_BH1750_ID is to create a unique sensor ID, which the Sensor Hub Application will use for performing further operations on sensors. This ID will be used from the Sensor Hub service layer and should be used to configure in sensor hub information structure present in the sensorhub_config.c file.

  • Step 3.1:
    Define a macro that defines the respective sensor and is unique.
    For Example,

    #define SL_CONFIG_SENSOR_LIGHT

  • Step 3.2:
    If one or more sensors are present with the same sensor type, then create an individual sensor ID in sl_light_sensor_id_t structure, which is present in */sensors/inc/sensors_config.h, for each sensor that needs to be created.
    For Example,

    typedef enum {
    SL_BH1750_ID = 0x01, /*!< BH1750 light sensor id*/
    SL_BH1750FVI_ID = 0x02,
    SL_LIGHT_MAX_ID,     /*!< max light sensor id*/
    } sl_light_sensor_id_t;

  • Step 3.3:
    Create the type of the sensor if not present in the sl_sensor_type_t structure and add in this structure which is present in the */sensors/inc/sensors_config.h file.
    For Example,

    //Type of sensors
    typedef enum {
    SL_NULL_ID,
    SL_LIGHT_SENSOR_ID,
    SL_SENSOR_TYPE_MAX,
    } sl_sensor_type_t;
    

• Step 4:

  Add your sensor condition based on the unique sensor ID in the sl_si91x_sensor_event_handler function, which is present in sensorhub_app.c, so that the user can print and check the sensor's data.

  Based on the sensor configurations made in the sensorhub_config.c file, the sensors' data is obtained.

  For Example,

  if (SL_SENSOR_BH1750_ID == sensor_id) {
    if (sensor_hub_info_t[sens_ind].sensor_mode == SL_SH_INTERRUPT_MODE) {
      DEBUGOUT("%f \t", (double)sensor_hub_info_t[sens_ind].sensor_data_ptr->sensor_data[0].light);
      } else if (sensor_hub_info_t[sens_ind].sensor_mode == SL_SH_POLLING_MODE) {
      if (sensor_hub_info_t[sens_ind].data_deliver.data_mode == SL_SH_TIMEOUT) {
        for (uint32_t i = 0; i < sensor_hub_info_t[sens_ind].data_deliver.timeout / sensor_hub_info_t[sens_ind].sampling_interval; i++){
          DEBUGOUT(" %f \t ", (double)sensor_hub_info_t[sens_ind].sensor_data_ptr->sensor_data[i].light);
        }
      }
      if (sensor_hub_info_t[sens_ind].data_deliver.data_mode == SL_SH_NUM_OF_SAMPLES) {
         for (uint32_t i = 0; i < sensor_hub_info_t[sens_ind].data_deliver.numofsamples; i++) {
            DEBUGOUT("%f \t", (double)sensor_hub_info_t[sens_ind].sensor_data_ptr->sensor_data[i].light);
          }
      }
      if (sensor_hub_info_t[sens_ind].data_deliver.data_mode == SL_SH_THRESHOLD) {
        DEBUGOUT("%f \t", (double)sensor_hub_info_t[sens_ind].sensor_data_ptr->sensor_data[0].light);
      }
    }
  }
  

• Step 5:

  Configure the pins and build the project. Please refer to the Sensor Pins Setup, Build and Executing the Application section in Readme of Sensor Hub project to check the sensor data

Introduction

Silicon Labs is committed to facilitating programs and avenues to develop “Qualified Solutions” that can be used to assist customers in expediting the certification of their “End Products” for Wi-Fi® technology.

The Wi-Fi Alliance is a global organization whose primary mission is to promote and advance the adoption of Wi-Fi technology worldwide. The alliance works to ensure that Wi-Fi products meet certain standards for interoperability, security, and performance, thereby enhancing the overall user experience. Devices are certified by testing against Wi-Fi Alliance test plans. Wi-Fi Alliance certification testing validates that the Device Under Test (DUT) meets interoperability and program requirements.

Overall, the Wi-Fi Alliance plays a crucial role in maintaining and advancing the quality and compatibility of Wi-Fi technology, which has become an integral part of our modern digital infrastructure.

This document outlines the certification programs to which the Silicon Labs devices underwent certification and an overview of the certification process. Additionally, it serves as a guide for customers in expediting the design of Wi-Fi CERTIFIED™ End Products.

Certification Process

• Any customer/OEM willing to apply for WFA Certification for their product should be registered as a member of Wi-Fi Alliance.
• Member shall apply to WFA resulting in the issuance of a CID (Certification Identification Number)
• The member collaborates with a convenient ATL (Authorized Test Laboratory) based on factors like location, time zone, etc. to arrange a test schedule, make financial arrangements, and provide the necessary equipment for the DUT (Device Under Test).
• In case the targeted device for certification is an ASD (Application Specific Device) and it cannot support the complete throughput requirements, the member needs to work with the ATL to arrive at an ASD test plan intended for that certification.
• WFA provides an Automation Framework with a Sigma Agent containing commands that need to be implemented by members to take necessary action on the DUT. This automation framework needs porting of the Sigma Agent based on the host platform being used while going for certification.
• The ATL conducts tests and furnishes test reports to both the member and the Wi-Fi Alliance for approval.
• In the event of a test failure, the member has the option to undergo re-testing. (Additional ATL fees may apply). However, the member is given time for fixes in the same cycle.
• The staff evaluates the results. Upon confirmation of the membership status, successful testing, and absence of other grounds for withholding certification, the product is granted certification.

Summary of Certifications

The RS9116 and SiWx917 undergo certification in the Connectivity, Security, and Optimization categories as part of the Wi-Fi Alliance. This is a station certification program. Below are the certification categories for RS9116.

SiWx917 supports Wi-Fi CERTIFIED 6 with 20MHz STA-only certification and Wi-Fi Agile Multiband™.

Wi-Fi Alliance accredited Test Labs

Wi-Fi Alliance certification procedures are conducted in three distinct types of test laboratories, following established guidelines. They include:

• Authorized testing Laboratories - ATL: ATLs are responsible for conducting the rigorous testing required for Wi-Fi devices to achieve Wi-Fi Alliance certification. ATLs are accredited to perform certification testing for Wi-Fi Alliance® members. Laboratories can be contacted directly for details on testing logistics, pricing, and any development/debugging services they offer. They perform Flex Track and Quick Track certification testing.
• Solution Test Laboratories - STL: A Solution Provider that has received accreditation from the Wi-Fi Alliance for testing and validating Qualified Solution candidates and Wi-Fi CERTIFIED products.
• Member Conformance Test Laboratory - MCTL: The member's in-house lab utilizes the QuickTrack Test Tool for testing their end product. This is typically an end product developer’s laboratory.

Wi-Fi Certification Paths

Eligible members will have the following options for certification:

• New Certification - Flex Track: Interoperability and conformance methodology to test and certify members’ end products using Wi-Fi Alliance test plans and test beds.
• Variant Certification - Quick Track: Wi-Fi Alliance methodology to test and certify end products when developed based on a Qualified Solution that includes a change to components and/or capabilities and maintains Wi-Fi interoperability. An end product may undergo QuickTrack testing at either an MCTL, STL, or ATL.
• Derivative Certification: Wi-Fi Certified product that has been modified but does not impact the Wi-Fi operation

For Example, 

1. The End Product user wants WFA certification for their IoT sensor device that uses a Silicon Labs SiWx917 module, then the Quick Track certification would be ideal here – where the Silicon Labs Qualified Solution is used without modification to Wi-Fi CC components.
   For this, the customer would need to become a member of the Wi-Fi Alliance and obtain a Certification ID.
2. The End Product user wants to certify their end-product that uses a SiWx917 chipset in NCP mode with their proprietary Host OS and RF frontend
   Then the flex-track path would be ideal here.

 Qualified Solution

The Qualified Solution is foundational to QuickTrack, a pathway for attaining Wi-Fi CERTIFIED end products. QuickTrack is tailored to products based on Qualified Solutions that have already undergone Wi-Fi core testing. It allows specific modifications to Wi-Fi components and functionality.

A Solution Provider generates a Qualified Solution by specifying the Wi-Fi Component Combination (Wi-Fi CC) and Wi-Fi capabilities present in the product.

The Wi-Fi Component Combination tracked by Wi-Fi Alliance include:

• Chipset
• RF architecture
• Firmware
• Driver
• Operating System (OS)
• Physical interface
• RF components
• Antenna

While a Solution Provider may incorporate supplementary components into the Qualified Solution, Wi-Fi Alliance will only document the specified Wi-Fi components mentioned above in the Certification System as a Wi-Fi CC.

Solution Providers can utilize Qualified Solution variants for their products, and/or offer their customers a selection between various Wi-Fi components or capabilities from the same Qualified Solution.

An end product developer can choose from any available variant of the Qualified Solution in the Certification System. Should an end product developer require adjustments to their Wi-Fi CERTIFIED end product, they can generate an end product variant.

QuickTrack shall be used to test and verify changes to any of the following components of the Wi-Fi CC:

• Operating System
• Physical interface
• RF components
• Antenna

Wi-Fi Alliance may allow an end product developer to utilize QuickTrack to test changes to the following components providing that Wi-Fi CERTIFIED assurances are met. Core testing is required to make changes to the following Wi-Fi CC components:

• Firmware
• Driver

A Solution Provider or end product developer shall not modify the following components of a Wi-Fi CC in a variant:

• Chipset
• RF architecture (including spatial streams and the number of radios)

Modifications to these components necessitate the development of a new product, i.e., a new Qualified Solution or a new Wi-Fi CERTIFIED end product. 

Abbreviations

1. WFA   -              Wi-Fi Alliance
2. ATL     -             Authorized Test Laboratory
3. OEM   -             Original Equipment Manufacturer
4. ASD    -             Application Specific Device
5. AMB   -             Agile Multi-Band
6. NCP    -             Network Co-Processor     
7. CC      -             Component Combination

References

1. Wi-Fi Alliance Certification Process
2. Quick Track Qualified Solution
3. Certification Overview

For queries on Wi-Fi Alliance Certification, contact Silicon Labs Support