BLE SDK Production Test

Last Updated on : 2022-11-24 09:20:09download

Before a Bluetooth Low Energy (BLE) device is connected to the Tuya IoT Platform, you must burn the authorization information to achieve one-key-per-device authentication mechanism. This topic describes the process and notes for BLE SDK production test.

This topic was no longer updated as of August 24, 2021. If you want to see the updated content, please refer to Bluetooth Device Access of TuyaOS.

Overview

During production, you must perform burning authorization and tests. You can use Tuya’s production test tools or purchase licenses in batches to use custom protocol and interface for authorization management.

  • If you use a custom interface to manage authorization information, set the BLE SDK not to manage the license according to the following configuration.

    #define TUYA_BLE_DEVICE_AUTH_SELF_MANAGEMENT 0
    

    If the above configuration is used, the application reads various ID information when initializing the BLE SDK. When a device is bound, the application writes the login key, VID, and bound flag sent by the SDK to the non-volatile memory (NVM).

  • If you use the Tuya production test tool for authorization and test and want the BLE SDK to manage authorization information, you can set the BLE SDK to manage the license according to the following configuration in this section.

    #define TUYA_BLE_DEVICE_AUTH_SELF_MANAGEMENT 1
    

Production test types

The production test is divided into general test and authorization as well as general device test. The protocol for the general device test is a subset of that for the general test and authorization.

  • General test and authorization includes authorization information burning, GPIO test, and RSSI test.

  • General device test includes additional custom tests. For specific protocol formats, see Bluetooth General Test and Authorization Protocol and Bluetooth General Device Test Protocol. Contact the Tuya project personnel to get the protocols.

    The BLE SDK has implemented the protocol for general test and authorization, but the RSSI test (the device under test scans a specific beacon), GPIO test, as well as additional test items based on the general device test protocol must be implemented according to the product definition.

Interfaces for these tests have been reserved in the tuya_ble_app_production_test.c source file of the BLE SDK. They are all weak implementations defined by __TUYA_BLE_WEAK. Your application only needs to redefine these functions in other source files and refer to them in the custom configuration file.

General test and authorization

General test and authorization includes authorization information burning, GPIO test, and RSSI test. The BLE SDK has integrated the function module for burning authorization information. You can use the following configuration:

#define TUYA_BLE_DEVICE_AUTH_SELF_MANAGEMENT 1

The BLE SDK also reserves interfaces for GPIO test and RSSI test. You only need to implement them according to the selected chip and product functions.

GPIO test

The GPIO test checks whether the PCBA has pseudo soldering or solder skips. Your application must customize the test method. The interface reserved for the GPIO test in the tuya_ble_app_production_test.c file is:

__TUYA_BLE_WEAK tuya_ble_status_t tuya_ble_prod_gpio_test(void)
{
    return TUYA_BLE_SUCCESS;
}

This function is implemented by your application, but it cannot be modified directly but must be implemented elsewhere.

RSSI test

The RSSI test checks whether the RF signal strength of the device is qualified. First, make a beacon to broadcast all the time. There are no special requirements for the broadcast content, as long as the device under test can recognize it when scanned.

The interface reserved for the RSSI test in the tuya_ble_app_production_test.c file is:

__TUYA_BLE_WEAK tuya_ble_status_t tuya_ble_prod_beacon_scan_start(void)
{
    return TUYA_BLE_SUCCESS;
}

__TUYA_BLE_WEAK tuya_ble_status_t tuya_ble_prod_beacon_scan_stop(void)
{
    return TUYA_BLE_SUCCESS;
}

__TUYA_BLE_WEAK tuya_ble_status_t tuya_ble_prod_beacon_get_rssi_avg(int8_t *rssi)
{
    *rssi = -20;
    return TUYA_BLE_SUCCESS;
}

The above three functions must be implemented by your application. But they cannot be modified directly but must be implemented elsewhere.

  • tuya_ble_prod_beacon_scan_start: Start to regularly scan the beacon, and get the scanned RSSI value.

  • tuya_ble_prod_beacon_scan_stop: Stop scanning and calculate the average of all RSSI values obtained.

  • tuya_ble_prod_beacon_get_rssi_avg: Return the average value of RSSI.

Example of implementing test interface

Suppose that you have created custom_app_product_test.c and custom_app_product_test.h files, and write the test code in custom_app_product_test.c, as shown below:

tuya_ble_status_t tuya_ble_prod_beacon_scan_start(void)
{
    //
    return TUYA_BLE_SUCCESS;
}

tuya_ble_status_t tuya_ble_prod_beacon_scan_stop(void)
{
    //
    return TUYA_BLE_SUCCESS;
}

tuya_ble_status_t tuya_ble_prod_beacon_get_rssi_avg(int8_t *rssi)
{
    //
    *rssi = -30;
    return TUYA_BLE_SUCCESS;
}

tuya_ble_status_t tuya_ble_prod_gpio_test(void)
{
    //Add gpio test code here
    return TUYA_BLE_SUCCESS;
}

Note: Do not add the __TUYA_BLE_WEAK declaration in the above snippet. Add the function declaration in custom_app_product_test.h.

#ifndef CUSTOM_APP_PRODUCT_TEST_H_
#define CUSTOM_APP_PRODUCT_TEST_H_


#ifdef __cplusplus
extern "C" {
#endif

#include "tuya_ble_type.h"

tuya_ble_status_t tuya_ble_prod_beacon_scan_start(void);

tuya_ble_status_t tuya_ble_prod_beacon_scan_stop(void);

tuya_ble_status_t tuya_ble_prod_beacon_get_rssi_avg(int8_t *rssi);

tuya_ble_status_t tuya_ble_prod_gpio_test(void);

void tuya_ble_custom_app_production_test_process(uint8_t channel,uint8_t *p_in_data,uint16_t in_len);

#ifdef __cplusplus
}
#endif

#endif // 

Add the macro definition to the config file defined in your application:

#define CUSTOMIZED_TUYA_BLE_APP_PRODUCT_TEST_HEADER_FILE "custom_app_product_test.h"

General device test

In addition to authorization information burning, GPIO test, and RSSI test, you can also define other test items based on Tuya’s test protocols and tools. The BLE SDK also reserves the interface for custom test items.

The interface reserved for the custom test items in the tuya_ble_app_production_test.c file is:

__TUYA_BLE_WEAK void tuya_ble_custom_app_production_test_process(uint8_t channel,uint8_t *p_in_data,uint16_t in_len)
{
    uint16_t cmd = 0;
    uint8_t *data_buffer = NULL;
    uint16_t data_len = ((p_in_data[4]<<8) + p_in_data[5]);
    
    if((p_in_data[6] != 3)||(data_len<3))
        return;
    
    cmd = (p_in_data[7]<<8) + p_in_data[8];
    data_len -= 3;
    if(data_len>0)
    {
        data_buffer = p_in_data+9;
    }
    
    switch(cmd)
    {   
        default:
            break;
    };    
}

For custom test items, you need to define the test command based on the Bluetooth general device test protocol. Contact Tuya’s technical staff to get the custom test software for PC or develop it yourself.

Production test tools

Currently, to use Tuya’s production test software, you must create a project on the Tuya IoT Platform, upload the firmware, and then place an order to get the authorization code. You also need to apply for a production test tool account. For more information about the production test tools, see Production Test Tools.