• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 2 answers
  • Subscribers 52 subscribers
  • Views 612 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

CC2640R2F: After a period of time, the CC2640R2 stops reporting beacons.

CC2640: Reporting beacons stops after a period of time

Mark Spavin
Prodigy 140 points
Part Number: CC2640
Other Parts Discussed in Thread: CC2650, , BLE-STACK, CC2540

I have a similar issue as described in this thread. The numbers are also the same, although I find my scanning stops at anywhere between 20-27 devices reported.

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1025896/cc2640r2f-after-a-period-of-time-the-cc2640r2-stops-reporting-beacons

I have built versions as Central and Peripheral/Observers and observe the same behaviour.

// Scan duration in ms
#define DEFAULT_SCAN_DURATION 0

With the scan period set to zero the scan should just continue, this in essence seems to be the case as I never get back GAP_DEVICE_DISCOVERY_EVENT to say that the scanning is complete.

The GAPCENTRALROLE_MAX_SCAN_RES parameter is set to 255 as setting this to 0 seems to stop ANY advertisements being received at all despite some documentation suggesting otherwise (i note in the central role it is clearly stated it will stop receiving). I also noted that in the examples the setting DEFAULT_MAX_SCAN_RES is used to set the GAPCENTRALROLE_MAX_SCAN_RES parameter and to create application storage for the returned data. 

I have the TGAP_FILTER_ADV_REPORTS parameter set to FALSE and I am receiving packets via GAP_DEVICE_INFO_EVENT, as the beacon I am looking for may have variable data. Even with the processing code cut to the bear minimum (no display no serial, no filters) so as not to slow the process (although this is a priority one thread waiting on ICall_wait) the problem still exists. When a number of devices have been reported 20-27 in my tests the ICall_wait fails to return. The system has not stopped and seems to still be operating if I then make a GAP_DeviceDiscoveryCancel(selfEntity) call when in this "stopped" state, the scanning is halted and the the subsequent GAP_DEVICE_DISCOVERY_EVENT is received. Restarting the scanning allows a further 20-27 devices to be received before the system stops receiving.

I have found the same operation in peripheral/observer and central roles, I have even reverted back to building the shipped examples with the smallest of tweaks and running them on the TI dev board. the results are the same. In very busy BT environments this means that scanning is halted very quickly. I have confirmed operation with low numbers for DEFAULT_MAX_SCAN_RES and can confirm when the max number is reached the scanning stops in exactly the same way, ICall_wait simply stops reporting any events as expected. As I can tell from the application variables this point is reached I could restart scanning, but in busy environments reducing the DEFAULT_MAX_SCAN_RES is not an option for our application. 

As this is being observed in products already deployed it would be good to find a solution that allows the expected operation to work. Our expectation would be to set the parameters as described above and when the buffer fills to restart scanning, with the GAPCENTRALROLE_MAX_SCAN_RES parameter set to 255, this still means a high number of stops and restarts in a busy environment but we feel it would solve our problem. Ideally when setting  GAPCENTRALROLE_MAX_SCAN_RES to 0 this should not store any packets (as suggested in some documentation) for the GAP_DEVICE_DISCOVERY_EVENT and rely solely on gathering the interesting packets from the GAP_DEVICE_INFO_EVENT.

From reading the referenced thread it would seem that this situation would not be improved by using the cc2640r2 or the 5.1 stack.

Any help to resolve this issue would be appreciated.

  • 0
    TI__Mastermind 37805 points

    Hi Mark,

    Are you able to replicate this with BTool on the latest SDK? I will assign an expert to comment in the meantime.

    Best,

    Nate

  • 0 in reply to Nathan Block
    Prodigy 140 points

    I have installed ble_sdk_2_02_06_07 and built the host_test stack and application successfully. This is running on a Rev1.3 CC2650 Launchpad. When I run up BTOOL everything seems to work but I cannot work out how to change the maxScanResponses. I can see the parameter under the Adv. Commands tab in the GAP_DeviceInit. The init data is sent to the device before I have access to the tree to change the values in GAP_DeviceInit, so the trace always shows 5 for the maxScanResponses.

    If I send a new GAP_DeviceInit command with maxScanResponses set to 255 I see the command go to the device but then I lose control of the device and can no longer stop and restart the scanning, I get a GAP_DeviceDiscoveryRequest Failed.

    In addition I also get a scan timeout error

    Until I can get my parameters to match in the BTool I cannot say if the problem is there or not. Having the maxScanResponses set t 5 always works on my target. The problem only occurs when the number of devices discovered gets to the 20-27.

  • 0 in reply to Mark Spavin
    TI__Guru** 101460 points

    Hi Mark,

    The issue might be due to some memory issue.
    When the number of devices to scan is larger, more RAM is required hence some potential problems.

    Best regards,

  • 0
    Prodigy 140 points

    Hi 

    "The issue might be due to some memory issue.
    When the number of devices to scan is larger, more RAM is required hence some potential problems"

    I had already guessed that this may be the case, but as the parameters are undefined, I find it would be hard to define a reliable working product. At a very minimum how much memory per scanned device and where and when this memory was allocated would help determine safe limits. At no point in any documentation have I found information suggesting the number of scan devices is limited to 'n'. In a modern environment a high number is required just to hear what is going on, unfortunately it seems many devices just advertise constantly and rapidly also many use random MAC's which compounds the problem.

    There is some documentation I have read but can no longer find, that suggests there is a way of scanning and the devices are not stored, the information is only available via the GAP_DEVICE_INFO_EVENT. This mode would be perfect for my application, but the runes to achieve this mode seem lost!!!

    With hard numbers I could at least assign more memory or calculate the impact of stopping the scanning and constantly clearing the buffers.

  • 0 in reply to Mark Spavin
    Prodigy 140 points

    Further information, I have found the document about unlimited scanning, albeit this is for cc2640r2. As this is a stack feature is it available in the stack used for the cc2640.

    https://dev.ti.com/tirex/explore/node?node=AD4sGbaamTCyn0DvZgBAsg__krol.2c__LATEST#:~:text=Scanning%20Basics&text=There%20are%20two%20types%20of,receive%20data%20from%20advertising%20device

    Enable Unlimited Scanning

    Certain applications require the ability to scan for an unknown number (i.e. unlimited) of devices. The Unlimited Scanning feature was developed for this reason. When enabling the unlimited scan feature, the stack passes the scan result to the application whenever a broadcaster/advertiser device is found. The BLE-Stack will not save the result in the stack and thus further save RAM usage. The application layer will then receive the scan result one by one under GAP_DEVICE_INFO_EVENT state.

    To enable this feature, simply set ENABLE_UNLIMITED_SCAN_RES to TRUE. This allows scanning without an upper limit of discovered devices.

    Similar to indefinite scanning, the number of scanned results is governed by DEFAULT_MAX_SCAN_RES as shown below.

    Value Description
    0 Enable unlimited scan. Scan results are only available under GAP_DEVICE_INFO_EVENT
    ~1-256 Maximum number of scan reports to application. Scan results are available under both GAP_DEVICE_INFO_EVENT and GAP_DEVICE_DISCOVERY_EVENT
  • 0 in reply to Mark Spavin
    TI__Guru** 101460 points

    Hi Mark,

    As you have mentioned, when scanning in a crowded environment, there is only little value into having unfiltered scan results.

    I would recommend to refer to the simple_peripheral / simple_central examples provided for the BLE-Stack (not BLE5-Stack) within the CC2640R2 SDK. The out of the box example simple_central example is configured to only keep the devices with the specific GATT service offered by simple_peripheral.

    I hope this will help,

    Best regards,

  • 0 in reply to Clément
    Prodigy 140 points

    Thanks for the information, but unfortunately it doesn't help. I understand how and what the various filters are doing, but unfortunately for my application I require to either be able to; know what memory is being used and calculate what the limits are, or to have unlimited scanning. I would be able to allow more memory where required and define the performance of the product. So the question come down to how do I enable Unlimited scanning in either BLE-Stack or BLE5-Stack when using a cc2640 OR how do I maximise the storage to hold this internal stack buffer.

  • 0 in reply to Mark Spavin
    TI__Guru** 101460 points

    Hi,

    For question related to CC2540, please open a separate thread.

    The examples I have pointed you to in my previous answer do enable unlimited scanning - and filtering is done in addition.

    When it comes to the memory available, it will depend on your application and how much memory is consumed by other elements. Scan results do not require the same space depending on the scan parameters.
    For example, when in unlimited scanning mode, no RAM is allocated by the stack. The RAM is allocated by the application, so you can precisely assess how much data is kept.
    For limited scanning, the stack allocates different RAM sizes depending on the parameters used. Usually I do my estimations with 20 bytes per results.

    Best regards,

  • 0 in reply to Clément
    Prodigy 140 points

    Sorry the cc2540 reference was a typo, this is cc2640 related, I have corrected the typo so other reader do not get confused.

    I will take another look at the examples, I have built both from the BLE-Stack and only moved to the BLE5-Stack on the advice of the first response. The "no RAM is allocated by the stack" when in unlimited mode is exactly what I would have expected. In my first look at the central example, I did not see how it enables unlimited scanning, maybe I missed something, can you point me to where this happens in the central example, as when I do what I believe I need to no output is produced from the stack. 

    Thanks again