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

4. Compiling, flashing, and testing the applications

Running these applications require a bootloader in the device, refer to the Preparation for this example section for details on creating and flashing a bootloader.
 

4.1 Compiling the applications

Whether you're importing the attached .sls files or creating your host, NCP, and SED applications following the instructions before, the first step for testing the applications is building them. Building the SED and NCP application can be done in Simplicity Studio using the "Compile" hammer icon.

The host application, it should be built on a Linux environment. An option for windows users is to use Cygwin. Simplicity Studio autogenerates a makefile that can be used to build the project by invoking the make tool from the Cygwin terminal while located in the folder containing the "Z3GatewayHost" project as follows:

> make all -j8

This will generate an executable file in the <project folder>/build/exe path. Further details can be consulted in the following KBA.
 

4.2 Flashing the applications

After successfully building the applications we need to flash the NCP and the SED application to their corresponding devices, in this case:

• NCP application - BRD4181B
• SED application - BRD4182A

Follow these steps to flash your applications:
 

• Right-click on the .s37/.hex output file and select "Flash to device..."
• This opens the "Flash programmer" window
• Click on the "Advanced Setting..." option
• In the pop-up window select the "Page Erase" option and click the "OK" button
  • This ensures that upon flashing the application only the pages to be programmed are erased, this is necessary to avoid unintendedly erasing the bootloader that is located in the main flash for Series 2 devices
• Back in the "Flash programmer" window press the "Program" button

> ./<application name>.exe -b 115200 -f x -p <com port of your NCP device>

> plugin network-creator start 1

> plugin network-creator-security open-network

> plugin find-and-bind target 1

Lastly, press button 0 in the WSTK of the SED, this will trigger the network steering process of the device allowing it to join the coordinator's network, identify the coordinator as a "find and bind" target and create a new binding entry in its binding table which as mentioned before is a requirement for the "Reporting" plugin. From this point onwards the SED sends a report to the coordinator for the measured Temperature and RH values from the sensor. The coordinators' application will parse the received payload and print the Temperature and RH values in the right format, this can be seen in the function emberAfReportAttributesCallback. The following picture shows the expected CLI output log from the host and SED:
 

As mentioned before, the SED can report the RH and Temperature values on command by pressing Button 0 after joining and establishing bindings. You should get a similar output on the SED side:
 

On the host side, the received messages output log will be the same as when the SED sends a scheduled report.

4.3.3.3 Using network analyzer to see reported values

Simplicity Studio offers a tool called "Network Analyzer" that allows displaying the OTA (Over the Air) messages. This is an extremely useful tool enabled by our WSTKs to inspect the network and understand what is happening in terms of data sent between devices, especially when tracking the network status through CLI messages becomes cumbersome.

To set up a Network Analyzer capture follow these steps:
 

• Press button 1 on the SED WSTK so that the SED leaves the network
  • Only needed if you want to observe the OTA association and binding process, otherwise skip this step
• In the Cygwin terminal, type the command keys print and copy the network key (NWK Key)
  • We need to provide this key to the Network Analyzer so that it can decrypt the OTA messages
  • Make sure that you have already created the network on the coordinator as a new key is selected during network formation

• In Simplicity Studio navigate to "Windows/Preferences", this opens the Preferences window
• Search for the items "Security Keys" (Located in "Network Analyzer/Decoding") and click on it
  • Here we can add new network keys to be used for decryption
• Press the "New" button, paste the previously copied network key and press the "Apply and close" button

• Under the debug adapters window locate your NCP device, right-click on it and select "Connect"
• Right-click again and select "Start Capture", this will open the "Network Analyzer" perspective.
  • You'll see a red dot that represents the coordinator device (As we're performing the capture from the NCP perspective)
• If your SED is NOT part of the network then repeat the steps from sections 4.3.3.1 and 4.3.3.2. Start by opening the network, formation is no longer required on the Host side. You should see all the association messages and the joining process of the SED into the coordinator's network
• After the first attribute report, you'll find in the "Transactions" window, an entry called ZCL: ReportAttributes, which corresponds to the automatic reports.
  • The image below shows the expected Network Analyzer output for the association process and the first attributes report message

• Click on it and on the right pane you'll find a section called "Event Details" that describes the contents of the payload
  • The payload is subdivided in multiple groups. For this specific case the relevant components that we should focus can be seen in the figure below:

The image above highlights contents from 2 main groups ZigBee Application Support and ZigBee Cluster Library, in the first one we see information relevant to the device sending the attributes report and its destination including the source and target endpoint, the reporting device profile ID, and the cluster been used for communication (0x0402 - Temperature Measurement). In the second group, we see information specific to the ZCL message sent, in this case, a report attributes command, as well as its direction (server to client), the attribute been reported (0x0000 - "measured value") and the actual value reported as a 16 bit signed integer.
 

For further details regarding the ZCL itself, the commands supported and details regarding the different clusters please consult the ZCL specification from the Connectivity Standards Alliance (CSA, previously known as ZigBee Alliance).
 

The steps described before to perform a Network Analyzer capture cover only a minimum portion of the capabilities of this tool, if you're interested in learning more about it please consult the following documentation and training:
 

• Tech talk session - Network analyzer training
• docs.silabs.com - Network analyzer documentation
• UG104 section 3 - Analyzing Network Analyzer Session Files

References

[1] https://community.silabs.com/s/article/how-to-build-an-ezsp-uart-host-application?language=en_US

[2] https://www.silabs.com/documents/public/application-notes/an706-ezsp-uart-host-interfacing-guide.pdf#page=5

[3] https://community.silabs.com/s/article/how-to-form-zigbee-3-0-network-with-emberznet-stack-x?language=en_US

[4] https://www.silabs.com/support/training/how-to-measure-and-debug-network-performance

[5] https://docs.silabs.com/simplicity-studio-5-users-guide/1.1.0/ss-5-users-guide-tools-network-analyzer/

[6] https://www.silabs.com/documents/public/user-guides/ug104-test-debug-apps.pdf#page=13

[7] https://zigbeealliance.org/wp-content/uploads/2019/12/07-5123-06-zigbee-cluster-library-specification.pdf