CC2340R5: Connecting devices - Central role, GAP Initiator

Hi, 

Thank you for reaching out. 

I would first of all encourage you to assess if the connection manages to be formed. This can be done looking at the RF debug signals of the device or using a more advanced Bluetooth sniffer than the one you have. For reference, the debugging guide shows how to enable the RF debug signals here. 

You should also ensure the device remains responsive, and check at the heap and stacks usage - see ROV usage here.

I hope this will help,

Best regards,

As you can see, everything is fine with heap and task.
The device remains responsive, the device is connecting via ble.

Hi, 

Thank you for sharing, the stack and heap look good. 

Here are other elements you should consider:

• I see you disable advertising before initiating a connection. This is a good idea as it maximize the air time available. However, your approach is not totally correct as advertising should be re-enabled only after the connection is established (or the connection establishment timeout is reached). 
• Ensure there is no mistake in the way the address to connect is passed to the device. You can ensure this by hardcoding it 
• I see only one connection is authorized (cf. SysConfig) - this number is the total number of connections (including the number of connections as central and as peripheral). 
• Ensure DEFAULT_INIT_PHY is the 1M PHY 

Best regards, 

Hi,
thanks for the answer.

1) The first thing I did was make sure that the address of the device I was connecting to was correct.

2) DEFAULT_INIT_PHY is the 1M PHY

3) I corrected the parameter Max Number of Connections = 2. The result is the same, events are missing.

4) Unfortunately, I don't have any other mechanism to check the connection than Wireshark. Since I don't have a debug board.

Hi, 

Ivan Kozhokar said:

4) Unfortunately, I don't have any other mechanism to check the connection than Wireshark. Since I don't have a debug board.

- Do you manage to reproduce the issue on a TI LaunchPad?

- If not already done, please check the following:

Clément said:

I see you disable advertising before initiating a connection. This is a good idea as it maximize the air time available. However, your approach is not totally correct as advertising should be re-enabled only after the connection is established (or the connection establishment timeout is reached). 

Best regards, 

1) Unfortunately, I don't have a TI LaunchPad in stock. I just ordered it on Friday and will be able to check it by the end of this week.
2) I tried not disabling ads at all, it doesn't help.
But the idea itself was the following. I disable ads before sending the BLEAppUtil_connect command. At the same time, I set the timeout to 7 seconds. As I understand it, the BLEAppUtil_connect command is blocking. And after the BLEAppUtil_connect command is finished, I can safely enable ads.

Please tell me. Can the CC2340 be simultaneously connected as a Peripheral and connect other devices to itself as a Central? Or is it necessary to break the peripheral connection when connecting other devices to the Central role?

Hi Clement,

Adding the latest update here:

I have looked at your recommended documents for enabling debug output RF.
I have added the settings to the SysConfig of the project:

Previously, Max Number of Connections was set to 1. As I understand it, this is the maximum number of connected devices.
But it is not clear in the documentation. Is it the total number of connections, which includes both Peripheral and Central?
Or is it the number of active connections only for Central?
After changing the Max Number of Connections parameter nothing has changed, there are still no connect events.

Then I need to connect to DIO9/3 and DIO11/5 pins with the analyzer and capture trace from these inputs.
Is it necessary to synchronize the trace at the moment of Connect start? And how to do it?
Can we use another pin for this purpose, to which logical 1 will be output at the moment of startup?

I wanted to emphasize a few more things that were not described in my initial email.
To start the connect, the function BLEAppUtil_connect(&connParams) is called.
In the structure connParams tried to set different timeout from 0 to 30000.
But the reaction to the BLEAppUtil_connect command was always the same.
No matter what timeout I set, the BLEAppUtil_connect command was always terminated in no more than 1 s and returned SUCCESS.
So either the command is not working correctly, or there is something wrong with the settings, or there is always a connection within 1 s.

And one more thing. If I set timeout = 0, then few times (2-3 times) in the BLEAppUtil_processGAPEvents(BLEAppUtil_msgHdr_t *pMsg) handler I received the GAP_CONNECTING_CANCELLED_EVENT event.
In addition, after the BLEAppUtil_connect command completes, I can connect device1 via peripheral.
So the ble-stack remains always active.

It turns out that I am currently missing the CC2340 kit.
I will ask our testers to send it to me or I will ask the hardware guys to solder wires to DIO9/3 DIO11/5 pins.
So there will be a slight delay in getting the trace.

Thank you,

Aida

Hi, 

Ivan Kozhokar said:

1) Unfortunately, I don't have a TI LaunchPad in stock. I just ordered it on Friday and will be able to check it by the end of this week.

What are the differences in your design vs the TI LaunchPad? Are you using a Low Frequency crystal (32 kHz)?

Ivan Kozhokar said:

As I understand it, the BLEAppUtil_connect command is blocking.

I am afraid there is a confusion here. BLEAppUtil_connect() is NOT blocking. 
My suggestion was then to ensure to keep advertising disabled until connection is established. 

Ivan Kozhokar said:

Please tell me. Can the CC2340 be simultaneously connected as a Peripheral and connect other devices to itself as a Central? Or is it necessary to break the peripheral connection when connecting other devices to the Central role?

The CC2340 is tested to maintain up to 8 connections simultaneously, both as central and as peripheral. 
My suggestion about disabling advertising was to maximize the available air-time but should not be required if the connection intervals and advertising intervals are large enough. 

Regards, 

Hi,

Aida Madelkhanova said:

Previously, Max Number of Connections was set to 1. As I understand it, this is the maximum number of connected devices.
But it is not clear in the documentation. Is it the total number of connections, which includes both Peripheral and Central?
Or is it the number of active connections only for Central?

I confirm you are referencing here the general configuration so you are setting the maximum number of connections (i.e. the sum of peripheral and central connections). 

Aida Madelkhanova said:

Then I need to connect to DIO9/3 and DIO11/5 pins with the analyzer and capture trace from these inputs.
Is it necessary to synchronize the trace at the moment of Connect start? And how to do it?
Can we use another pin for this purpose, to which logical 1 will be output at the moment of startup?

 In general, the radio activity expected in the various states is quite recognizable so you should not need anything special here. If you do want to "mark" you logs, you can toggle a third GPIO right before calling BLEAppUtil_connect().

Aida Madelkhanova said:

I wanted to emphasize a few more things that were not described in my initial email.
To start the connect, the function BLEAppUtil_connect(&connParams) is called.
In the structure connParams tried to set different timeout from 0 to 30000.
But the reaction to the BLEAppUtil_connect command was always the same.
No matter what timeout I set, the BLEAppUtil_connect command was always terminated in no more than 1 s and returned SUCCESS.
So either the command is not working correctly, or there is something wrong with the settings, or there is always a connection within 1 s.

This behavior is expected as BLEAppUtil_connect() is not a blocking function. 

I hope this will help,

Regards, 

Hi,
thanks a lot for the clarification.
There is a warning in the SimpleLink CC23xx SDK BLE5-Stack User's Guide under the GAP Initiator

<When initiating timeout is set to 0 (wait indefinitely), the CC23xx will stay in initiator role until a connection is successfully established. If the peripheral device disappeared from the network before the connection is established, the only method for initiator to exit this state is to call GapInit_cancelConnect() or BLEAppUtil_cancelConnect().>

I was confused. From this warning I understood the following. After calling the BLEAppUtil_connect() function, go into Initiator mode and everything is blocked until a connection is established or must issue the BLEAppUtil_cancelConnect() command to exit Initiator mode.
A non-zero timeout works in the same way. After the specified timeout, the Initiator will either connect the device with the <BLEAPPUTIL_ESTABLISHED_EVENT> event or with the <BLEAPPUTIL_CONNECTING_CANCELLED_EVENT> event and terminate its work.

This is what our implementation looks like

Hi, 

May I kindly suggest you to request a design review following this link: https://www.ti.com/tool/SIMPLELINK-2-4GHZ-DESIGN-REVIEWS

Best regards, 

Hi,
Thank you for your suggestion.
We will use this service through our regional manager and perform a design review.

Hi,
I got LaunchPad on CC2340R5.

Took the original project basic_ble from sdk_8_10_01_02.

Made changes to sysConfig:
1)  Device Role  = <Peripheral + Central>
2) Max Number of Connections = <2>

Added a task iBus_task that, after 30 seconds, tries to connect a device with a specified address.
This task is run in app_main.

void appMain(void)
{
    // Call the BLEAppUtil module init function
    BLEAppUtil_init(&criticalErrorHandler, &App_StackInitDoneHandler,
                              &appMainParams, &appMainPeriCentParams);
     iBus_createTask();

}

void *iBus_task(void *arg0)
{
     struct timespec taskTimer;
     // Create semaphore
     int32_t semConnectStatus = sem_init(&semConnect, 0, 0);
     if (semConnectStatus != 0)
     {
          /* Error creating semaphore */
          while (1) {}
     }

    for(;;) {
         // Semaphore check period 30s
         clock_gettime(CLOCK_MONOTONIC, &taskTimer);
         taskTimer.tv_sec += IBUS_WAIT_SEMAPHORE_SEC;
         // Waiting for semaphore
         sem_timedwait(&semConnect, &taskTimer);
         Start_Connect();
    }
}

static bool Start_Connect(void)
{
    // Address device
    uint8_t addr[8] = {0x28, 0xE0, 0x03, 0x50, 0xBF, 0xA0, 0, 0};
    bool ret = false;
    // Check connect
    if (flag_connect == false) {
         GPIO_write(CONFIG_GPIO_LED_GREEN, 1);
         // Set the connection parameters
         BLEAppUtil_ConnectParams_t connParams = {
             .peerAddrType = ADDRTYPE_PUBLIC & MASK_ADDRTYPE_ID,
             .phys = INIT_PHY_1M,
             .timeout = 10000,
         };
         // Copy the selected address
         memcpy(connParams.pPeerAddress, addr, B_ADDR_LEN);
         //Initiate a connection
         if (BLEAppUtil_connect(&connParams) == SUCCESS) {
            ret = true;
        }
        GPIO_write(CONFIG_GPIO_LED_GREEN, 0);
     }
return ret;
}

I am launching the project for execution.
Check that the stack started without errors.
After 30 seconds, the Start_Connect function is called and all freezes.
I go step by step and find the place where it hangs.

In the module <icall_POSTFIX.c>, the function <icall_directAPI>.

ICALL_ERRNO_UNKNOWN_THREAD = -5
When this function is called from a thread which has not registered an entity, either through ICall_enrollService or through ICall_registerApp.

The Start_Connect function is called in a similar way on my standard device, but it doesn't hang there and there is no error.

Hi, 

Ivan Kozhokar said:

ICALL_ERRNO_UNKNOWN_THREAD = -5
When this function is called from a thread which has not registered an entity, either through ICall_enrollService or through ICall_registerApp.

As you stated, the ICALL_ERRNO_UNKNOWN_THREAD is raised if the thread/task accessing the BLEStack has not registered calling ICall_registerApp. When using the BLEAppUtil framework, this call is made within BLEAppUtil_stackRegister. 
The same is documented here: https://software-dl.ti.com/simplelink/esd/simplelink_lowpower_f3_sdk/8.10.01.02/exports/docs/ble5stack/ble_user_guide/html/freertos/tasks.html#creating-additional-icall-enabled-tasks 

To fix your issue, I believe you should:

1. Open SysConfig -> BLE -> Advanced Settings -> ICALL and add one to the “Max Number of Icall Enabled Tasks” entry.

2. Add the following code at the beginning of iBus_task()
   

   // Register to the stack and create queue and event
   BLEAppUtil_stackRegister();

   
   

I hope this will help,

Best regards, 

Hi,
I made all the changes you suggested, but it didn't solve the problem.
The error is still the same ICALL_ERRNO_UNKNOWN_THREAD = -5.

I don't understand why we need to perform another registration AppUtil in the stack?
We already did this at the BLEAppUtil_init stage, when we created the BLEAppUtil_createBLEAppUtilTask ​​task.

I remade the Start_Connect function call.
Now there is no error and the connection appeared as an event BLEAPPUTIL_LINK_ESTABLISHED_EVENT. I also got the number of the connected counter.
It turns out that it works on LaunchPad Connect.
I will try to compare how the settings of the original basic_ble project differ from the standard software.

Tell me, if I received the event BLEAPPUTIL_LINK_ESTABLISHED_EVENT.
Is the value gapEstMsg->devAddr the real value received during connection?
Or is it the address specified in the BLEAppUtil_ConnectParams_t structure?

Hi,

The address held by gapEstMsg->devAddr when receiving a BLEAPPUTIL_LINK_ESTABLISHED_EVENT is the address received during connection. 

Regards, 

Hi,
Tell me, what time should be set in Central Configuration for Supervision Timeout?
And how it should correlate with timeout in the BLEAppUtil_ConnectParams_t structure?

BLEAppUtil_ConnectParams_t connParams = {
.peerAddrType = ADDRTYPE_PUBLIC & MASK_ADDRTYPE_ID,
.phys = INIT_PHY_1M,
.timeout = 5000,
};

Hi,
I want to emphasize the following. It was determined at random.
If in the Central Configuration the Supervision Timeout parameter is set to be greater than the timeout in the BLEAppUtil_ConnectParams_t structure, then everything works and events are issued.
It turns out that the GapInit_connect function should monitor these parameters and return an error, but in fact it always returns SUCCESS.