CC2541: Indication stops unexpectedly

Lin,

I will assign an expert to help you. I have some questions that will help us assist you:

• Are you using simple_peripheral?
• Does your code have modifications?
• Are both central and peripheral implemented in CC2541 devices (separately)?

Thanks,

Luis

Hi Luis,

I'm updating from a custom project developed based on the older version of simpleBLEcentral (1.4.0). I haven't touched the peripheral side yet, hoping to not introduce additional variabilities into the process. Peripheral is on stack 1.4.0, both are implemented in cc2541. 

Thanks,

Lin

BLE Stack 1.5.0 is not the latest Stack version. I would suggest you to use BLE-CC254x-1.5.1.1 and  test original SimpleBLEPeripheral to see if you can see the same issue first.

Hi Yikai,

I've tried to use the CySmart App to receive indications on iPhone 11 connected to the same peripheral. That doesn't seem to have any problem. 

How would loading the simpleperipheral tell me anything about the central?

Also, I do realized that 1.5.0 is not the latest, but the software development guide said to bring it up to 1.5.0 first before going to 1.5.1. What's the reason behind that? or that's negligible? 

Thanks,

Lin

I couldn’t understand your question about “ How would loading the simpleperipheral tell me anything about the central?”.

I would say you can use 1.5.1 directly without bring up 1.5.0 first.

Hi Lin, 

I agree with YK, you can go directly to v1.5.1 without porting to 1.5.0 first. 

If you load the default peripheral project on another board, you can test that connection with the central device. 

Thanks, 
Elin 

Hi Elin,

Do you mean to load 1.5.1 to Central and try 1.4.0 peripheral? 

I need the new central to work with peripheral that was installed long ago. 

Lin

You can use SimpleBLECentral and SimpleBLE Peripheral in BLE Stack 1.5.1.

I tried to replace all the lib and ,c and .h files.

Doesn't seem to make a difference. 

Any other thoughts? I'll try to use the SimpleBLEcentral instead. 

Replacing all the lib and .c and .h files? Do you test original SimpleBLECentral and SimpleBLE Peripheral in BLE Stack 1.5.1 to verify if you see the same issue?

Screenshot from the sniffer. the master sides doesn't even register the indication events anymore after the last ATT value of 261A3B0931.

What are the message of empty PDUs? 

I'm attaching the entire packet sniffer output. Haven't done the 1.5.1 yet on the peripheral/slave side yet. Slave is still on 1.4.0 stack, but it works with 1.4.0 master very well. 

Anything obvious you see? 

Stack1_5_0.psd

Hi Lin, 

Can you share some details about your use-case and what changes you have made in the projects? In the screenshot/log you attached, are you using modified versions of both examples or only the central or peripheral? Can you test the connection using the default projects from the 1.5.1 SDK and see if you still have the same issue?

Thanks, 
Elin

Hi Elin,

I currently have a dual redundancy, where I have two sets of peripheral and central. They both need to be connected. I've started to upgrade one of the two centrals, but nothing else so far. 

I've carried over my user defined functions under the APP tree, copied over all the other necessary .c, .h and lib files overwriting what was there before. The project config was carried over during importing from 1.4.0 stack using older version of IAR workbench (8.20). 

Screenshot is showing modified version of one of the central/peripheral pair. This is a released product based on 1.4 stack, and I'm trying to bring it up to 1.5.x. If I load our released firmware based on 1.4.0 stack, there is no issue or dropping of the GATT indications. Does this answer your question? 

What I also noticed is that it doesn't get into the "if ( events & SYS_EVENT_MSG )" condition anymore. my custom functions are setup in the same way as the simpleBLECentral.c, xxxx_ProcessEvent( ) then looks for SYS_EVENT_MSG and then calls the ProcessOSALMsg() from there, then release the osal message, then returns. 

    if ( events & SYS_EVENT_MSG )       //0x8000
    {
        uint8 *pMsg;
        if ( (pMsg = osal_msg_receive( simpleBLETaskId )) != NULL )
        {
            
            simpleBLECentral_ProcessOSALMsg( (osal_event_hdr_t *)pMsg );
            /* Release the OSAL message*/
            VOID osal_msg_deallocate( pMsg );
            if(verboseEnabled)
            {
              numberOfChar =sprintf(str,"0x8000");
              SendStringToHost( );
            }
        }
        else{
          numberOfChar =sprintf(str,"Null");
          SendStringToHost( );
        }
        /* return unprocessed events*/
        return (events ^ SYS_EVENT_MSG);
    }

So when can see the Indication ACK stops, I'll enable verbose. I got nothing related to this event printed out. 

static void simpleBLECentral_ProcessOSALMsg( osal_event_hdr_t *pMsg )
{

    switch ( pMsg->event )
    {
    case GATT_MSG_EVENT:
        simpleBLECentralProcessGATTMsg( (gattMsgEvent_t *) pMsg );
        break;
    }
}

This function above is pretty much the same as the sample code in simpleBLEcentral.c. 

simpleBLECentralProcessGATTMsg function then has our parsing for the actual payload. It looks like the chain has stopped long before getting to parsing the message. 

Is there any reason that the SYS_EVENT_MSG is no longer registered? 

Hi Lin, 

Thanks for sharing. 

Have you been able to form a connection with your modified version of central and a default peripheral in the new SDK? I see that you've tried with a new central and an old peripheral but I didn't find any information with central/peripheral on the new SDK. 

Did you follow the migration guide then porting your solution to the newer SDK?

Thanks, 
Elin

Hi Elin,

Yea, I did follow the one page migration instructions to the newer SDK. SWRU271I pg 81-84. 

My pin out is different from the SimpleBLE projects. it may take me a while to set that up. 

I noticed that the 0x8000 event stops showing up once the MD bit in the Data Header is set. See P.nbr. 1155 below. 

The central doesn't expect any more data but the MD bit is set for some reason. I'll look at the peripheral side to figure out why the MD bit is set. But, is there a way to just treat the MD bit as a dirty bit and continue? It almost feels like the central is expecting more messages but in reality there's none. I wonder if that's why it stops registering 0x8000 events from that point on. I've tried this multiple times and it appears to be a pattern where the central stops getting 0x8000 event once the MD bit is set. 

Also, what's up with the Empty PDU? Is that a way that the physical layer keeps the connection alive? 

Hi Lin,

Have you been able to form a connection with your modified version of central and a default peripheral in the new SDK? I see that you've tried with a new central and an old peripheral but I didn't find any information with central/peripheral on the new SDK. 

Lin said:

The central doesn't expect any more data but the MD bit is set for some reason

How do you know that the central isn't expecting more data? 

Lin said:

Also, what's up with the Empty PDU? Is that a way that the physical layer keeps the connection alive? 

This is known as a connection event that will occur at every connection interval. If the slave device has no slave latency (0) it will reply with an ack to every connection event packet sent from the master. If the master does receive any ACK within the set supervision timeout it will exit the connection. Please read more details of connection events in the Adopted Bluetooth Core Specification found here:
www.bluetooth.com/.../adopted-specifications

Thanks, 
Elin