CC2541: Issue with BLE timing in new stack

Luke

Part Number: CC2541

Tool/software:

Hi team,

I am running into some timing issues with my customer who is using 2 CC2541 chips on their board, one master and the other slave. They have no issue updating the stack to BLE 1.5.2 on master chip. However, when they upgraded the slave chip from 1.3.1 to 1.4.1 or even 1.5.2, they ran into the same issue where they don't get any SYS_EVENT_MSG anymore. They also updated the min and max conn interval to 8 and 10 on slave, but it is not helping at all.

Appreciate any pointers you could give on this issue.

In SimpleBLECentral,

 if ( events & SYS_EVENT_MSG )
    {
        uint8 *pMsg;
        if ( (pMsg = osal_msg_receive( ALPReceiverSlaveBLETaskId )) != NULL )
        {
            simpleBLECentral_ProcessOSALMsg( (osal_event_hdr_t *)pMsg );
           
            // Release the OSAL message
            VOID osal_msg_deallocate( pMsg );
        }
        // return unprocessed events
        return (events ^ SYS_EVENT_MSG);

Another question I have is from gap.h. It looks like structure gapEstLinkReqEvent_t has a new variable defined called connRole and the description says connection formed as master or slave. Is there any other purpose to this variable than defining the role since it was not included in previous versions but still worked as expected?

Thanks,

Luke

10 months ago

0 David 10 months ago

TI__Genius 15535 points

Hello Luke,

Thanks for reaching out. We will look at the question and come back as soon as possible.

BR,

David.

0 Jan 10 months ago

TI__Mastermind 42100 points

Hi Luke,

Is the missing SYS_EVENT_MSG and non-updating connection interval occurring in a custom project or an unmodified SDK example? If it is in a custom project, then can you check if the same happens in an SDK example?

Best Regards,

Jan

0 Luke 10 months ago in reply to Jan

TI__Expert 3770 points

Jan,

They have 2 central (both spin-off from simpleBleCentral example) but only the 2^nd central is having this issue.

We looked at function osal_run_system() in osal.c, and are seeing event 0x8000 which is SYS_EVENT_MSG in their index task, so don't understand why SimpleBLECentral_ProcessEvent is not seeing event SYS_EVENT_MSG.

They also don't have this issue with the older BLE stack 1.31.

tasksEvents[idx] |= events;

Best,

Luke

0 Jan 10 months ago in reply to Luke

TI__Mastermind 42100 points

Hi Luke,

Understood, can you share the main differences between their centrals? Maybe understanding the difference between these can help us find what may be going on.

Best Regards,

Jan

0 Luke 10 months ago in reply to Jan

TI__Expert 3770 points

Hey Jan,

The main central does all the processing and execution task. It's connected to the secondary central via I2C. The secondary central will try to pair with peripheral. They have no issue with pairing, but after pairing they're only receiving one or 2 packets from peripheral and then no more for a long period of time. They should be getting a packet at 40ms interval. They're wondering if BLE 1.5.2 introduced any changes to how master/slave central behaves.

Best,

Luke

0 Jan 10 months ago in reply to Luke

TI__Mastermind 42100 points

Hi Luke,

The only change introduced in the 1.5.2 release was a fix related to pairing which seems to be unrelated to the behavior observed. However, the releases between the 1.3.1 and onward do each contain many changes. The list of all of these may be found here: https://software-dl.ti.com/simplelink/esd/ble_stack_1_x/1.05.02.00/exports/README.txt

Taking a step back, could you share why the customer is looking to migrate? If they have a stable solution in the original SDK then it may make sense to stay in the previous version.

Best Regards,

Jan

0 Luke 10 months ago in reply to Jan

TI__Expert 3770 points

Jan,

The customer ended up finding the cause of the issue themselves. They discovered the cause of the issue was due to not sending ATT handle confirmation for one of the handle values. After adding code to send confirmation, they're now seeing packets coming at 40 ms interval.

Thanks for the help!

Luke

Bluetooth®︎

Bluetooth forum

CC2541: Issue with BLE timing in new stack