This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2652R: Command line scripts for automated Bluetooth Low Energy Testing

Part Number: CC2652R
Other Parts Discussed in Thread: CC2640R2F

Hello,

We use BTools to connect to and test our devices during production. We use an Autohotkey script at the moment to automate sending and receiving data between a CC2640r2f launchpad and our end product. What we would like to do, is use a command line script of some sort to connect and interact with the launchpad instead of using BTools. Any guidance on where to begin would be greatly appreciated!

Tyler

  • Hi Tyler,

    I would recommend to take a look at this thread:

    https://e2e.ti.com/support/wireless-connectivity/bluetooth/f/538/t/465834

    HCI Tester introduces a scripting language that requires less clicks and is more flexible than BTool. However we don't have a CLI for HCI tester either.

    BR,

    Sean

  • Hello,

    Thanks for the quick response. I looked into HCI Tester and got it connected to my device. I can establish a connection, authenticate, update passkey, and terminate link using the sample script file. 

    I know the software is given as is, but is there any additional documentation on using any type of structures such as if, for, while, etc? As well, is there a way to have a prompt open up to enter a given BLE slave address rather than manually entering it in the script itself. 

    My hopes is to remove autohotkeys and use the HCI Tester. My current script links an excel spreadsheet that has my slave addresses and our products serial numbers which allows me to easily enter the desired address. After connecting my devices (I currently run 4 BTools in unison to test 4 devices at a time), I read and write to several characteristics. I parse what is read in order to determine the next write commands. 

    My issue with the current setup is that it is hard to expand my test codes and BTools gets hung up reading the devices sometimes. As well, there are certain text boxes and objects that Autohotkey can't access for whatever reason.

    It would be really nice if TI would develop some kind of CLI to help automate Bluetooth testing for large production runs. 

    Thanks,

    Tyler 

  • Hey Sean,

    I've decided to go a different route and modify the host code directly by injecting BLE commands from the Launchpad after hitting one of the buttons. However, I am having trouble writing to my characteristics. I basically post a semaphore to a new Task that is Icall registered. Here is the part of the task where I try to write 31:31:00 to a characteristic handle at 0x000b.  

        char signal[3]="11";
        SignalStrength.handle=0x000b;
        SignalStrength.len=3;
        SignalStrength.pValue=(uint8 *) &signal[0];
        SignalStrength.cmd=0;
        SignalStrength.sig=0;
        while(1) //main infinite loop
        {
    
            Semaphore_pend(semAutoWrite,BIOS_WAIT_FOREVER);
    
            status= GATT_WriteCharValue(0x0000,&SignalStrength,selfEntity);
    }

    I am still connected using BTools, but now all reads using the gui interface returns ble pending on writes and reads. Am I using the wrong command? Or Is there a certain way to insert this call into the NPI or the host task? 

  • Hi Tyler, 

    I have attached a guide that seeks to document the intrinsic commands of the HCI tester scripting language

    /cfs-file/__key/communityserver-discussions-components-files/538/HCITester-Quick-Reference.pdf

    >> I know the software is given as is, but is there any additional documentation on using any type of structures such as if, for, while, etc? As well, is there a way to have a prompt open up to enter a given BLE slave address rather than manually entering it in the script itself. 

    I don't believe this is possible using HCI tester, but I do have an idea. You could create an HCI tester script that stores the address as magic token, for example:

    myBdAddr = __ADDR__

    Then you could write a small script (Python or sed or something like that)  that reads the address from the LaunchPad using http://www.ti.com/tool/download/FLASH-PROGRAMMER-2 

    and replaces __ADDR__ in the script. Finally you could run the script. Not ideal, I know, but possible.

    Regarding the idea of injecting the commands in the FW, this is okay too, but I suspect that it may take up valuable flash space in your product.

    For the specific issue you have posted, I believe the issue is that you're writing to the GATT layer faster than the stack is sending out packets or the peer is acknowledging them.

    There are two things at play here:

     1. Only one synchronous GATT procedure may occur at a time (such as write char value). Any attempts to do another write will result in blePending

     2. Once the stack has reached MAX_NUM_PDU of packets queued up from host to controller  it will not accept more and an error will be returned.

    Have you checked that your GATT writes are 1. being acknowledged by peer device and 2. being sent out

  • Hello Sean,

    The Quick Reference does provide a lot of clarification of what can be done with HCI Tester. It still would not help to fully automate the process.

    I'm not sure if the Flash Programmer 2 idea would work since our products are tested over Bluetooth using a launchpad as the link between computer and our final product.

    What I meant by injecting the code into FW was on the given Host_test project that the launchpads use with BTools. So the code would go on the launchpad, not the final product.

    With the BLE Pending, I think I was trying to write commands too fast, but I'm not entirely sure this is the entire reason.

    In the end, I wrote a Powershell gui that connects over the com ports to a launchpad, and then establishes a BLE link with our product. It also can pull in csv files, performs the automated tests, and can log and display information.

    If I have anymore questions I will post a new question linking back to this post.

    Thanks once again Sean for the insightful information and help!

    -Tyler