CC2652R: BLE Continuous scan stops issue (SDK 5.20.00.52)

Part Number: CC2652R

SIMPLELINK-CC13X2-26X2-SDK 3.40.00.02  : ble5_host_test_cc26x2r1lp_app on CC2652R1F

During the continuous scanning:

1. Sometimes the HCI event 0x682 is received during the scanning. We didn’t find this event definition. Why we get this?
2. Sometimes the PACKET_TYPE of HCI packets “0” is received. {PacketType = 0 EVENT = 3C}. Any interpretation?

Note: the same commands were sent through UART as mentioned above.

Hey Sen,

I've assigned your post to an expert to assist with.

I noticed you posted a very similar question as the one above, so I've merged the two threads into one here. I hope that's ok. Feel free to add on if I've missed anything when merging the threads.

Thanks Ammar. 

Those are two different issues with different SDK but related to the BLE Scan.  If someone can answer both issues, that will be great. 

-Sen-

Hi Sen,

I have managed to reproduce the issue you have described with SDK 5.20. However, the issue does not reproduce with SDK 5.10.

My next step is to enable the radio debug signals (see here) to assess if the error is coming from the radio or from a different level.

Best regards,

Thanks a lot @Clément for reproducing it.

Hi Sen,

Can you try to change the MAX_NUM_WL_ENTRIES in ble_user_config.h. I think this should resolve your issue. This is related to a fix that was implemented between 5.10 and 5.20 for duplicate filtering.

Best,

Nate

What is the number you recommend for MAX_NUM_WL_ENTRIES ?  

Thanks Nathan,

MAX_NUM_WL_ENTRIES = 64, it just stops after 64 scans.

MAX_NUM_WL_ENTRIES = 256, no scan results received.  please advise on this.

Hi Sen,

Can you try 255? I think 256 will be a problem because MAX_NUM_WL_ENTRIES gets cast to a uint8_t in ble_user_config.c

// BLE Stack Configuration Structure
const stackSpecific_t bleStackConfig =
{
  .maxNumConns                          = MAX_NUM_BLE_CONNS,
  .maxNumPDUs                           = MAX_NUM_PDU,
  .maxPduSize                           = 0,
  .maxNumPSM                            = L2CAP_NUM_PSM,
  .maxNumCoChannels                     = L2CAP_NUM_CO_CHANNELS,
  .maxWhiteListElems                    = MAX_NUM_WL_ENTRIES,
  .maxResolvListElems                   = CFG_MAX_NUM_RL_ENTRIES,
  .pfnBMAlloc                           = &pfnBMAlloc,
  .pfnBMFree                            = &pfnBMFree,
  .rfDriverParams.powerUpDurationMargin = RF_POWER_UP_DURATION_MARGIN,
  .rfDriverParams.inactivityTimeout     = RF_INACTIVITY_TIMEOUT,
  .rfDriverParams.powerUpDuration       = RF_POWER_UP_DURATION,
  .rfDriverParams.pErrCb                = &(RF_ERR_CB),
  .eccParams                            = &eccParams_NISTP256,
  .fastStateUpdateCb                    = NULL,
  .bleStackType                         = 0,
#ifdef CC2652RB_LAUNCHXL
  .extStackSettings                     = EXTENDED_STACK_SETTINGS | CC2652RB_OVERRIDE_USED,
#else
  .extStackSettings                     = EXTENDED_STACK_SETTINGS,
#endif
  .maxNumCteBuffers                     = MAX_NUM_CTE_BUFS
};

line 316 of ble_user_config.c

typedef struct
{
  uint8_t                     maxNumConns;
  uint8_t                     maxNumPDUs;
  uint8_t                     maxPduSize;
  uint8_t                     maxNumPSM;
  uint8_t                     maxNumCoChannels;
  uint8_t                     maxWhiteListElems;
  uint8_t                     maxResolvListElems;
  pfnBMAlloc_t                *pfnBMAlloc;
  pfnBMFree_t                 *pfnBMFree;
  userConfigRfDriverParams_t  rfDriverParams;
  ECCParams_CurveParams       *eccParams;
  pfnFastStateUpdate_t        fastStateUpdateCb;
  uint32_t                    bleStackType;
  uint32_t                    extStackSettings; // | reserved | use CC2652RB | MasterGuard |
                                                // |   31..2  |       1      |      0      |
  uint8                       maxNumCteBuffers;
} stackSpecific_t;

line 494 of ble_user_config.h

Sorry Nate, 

MAX_NUM_WL_ENTRIES 255 is not initializing  the chip at all. No scan results. Even 128 does not work. Please verify and give us a good recommendations. I think the we are configuring the wrong parameter. Only 64 works for me and stops after 64 scan results. Not 100/128/255.

#ifndef MAX_NUM_WL_ENTRIES
#define MAX_NUM_WL_ENTRIES 255 // at 8 bytes per WL entry
#endif

Line 235. 

Hi Sen,

I am able to replicate the behavior you're describing. Can you give us broader context to the task you're trying to accomplish here? As you increase the MAX_NUM_WL_ENTRIES, you are increasing the amount of memory used to hold all the data you're being returned. This may be problematic as you make the MAX_NUM_WL_ENTRIES bigger and bigger. You might consider a framework where you alternate between scanning and parsing the results of the scans to keep memory usage to reasonable level. Is that a possibility?

Best,

Nate

We need to do continuous scan until we stop. It used to work but not working with SDK 5.20.00.52. I guess,  Clément  is trying to debug further. 

Hi Sen,

Yes Clement and I are coworkers! He is a talented engineer, and he's transferred this thread over to me. While I understand that you want to keep your device in scanning mode continuously, this is not feasible on our devices because the number of devices you'll find may exceed the memory requirements of the device.

What I am suggesting is that you make it seem like you're doing a continuous scan by alternative between scanning and processing the scan results. This will let you maintain a long scan time to detect all your devices without running out of memory. Is that a feasible alternative? 

Hi Nathan Block;

We do not do much processing of scan results. We just copy the scan result and pass it to another process. That process will do the processing. We clear the UART buffer continuously.

The SDK 3.40.00.02 & 5.10.00.48 works fine but not  5.20.00.52. That is the issue. 

SDK 5.20.00.52 scan only 64 tags maximum and stops , that is not expected. Is that your design changed between the SDKs? I guess, there should be bug in the SDK. 

-Sen-

Hi Sen,

I apologize for the delayed response. I understand your frustration that the SDK doesn't seem to function the same way from one update to the next. I'm working with our R & D team to close this issue out, and I'll keep you updated as I learn more. If you do not hear anything by the end of the week, please feel free to ping the thread.

Best,

Nate

Thank you Nate.