CC2640 Central max Scan results or unlimited ?

Hello user,
To scan for more devices use shorter scan duration's and restart the scan instead. Read more details in this thread:
e2e.ti.com/.../501697

Hi Eirik,

Thanks for your reply.

1.
We do the scan loop: Scan --> GAP_DEVICE_DISCOVERY_EVENT --> next Scan...
modified DEFAULT_MAX_SCAN_RES to 8 ,and set the DEFAULT_SCAN_DURATION to 100.  about 10 hours, the loop stoped.
In fact, we don't known no GAP_DEVICE_DISCOVERY_EVENT or Crash.

2.
i defined the HEAPMGR_PROFILER of heapmgr.h,
add counter in HEAPMGR_MALLOC() and HEAPMGR_FREE(), and MALLOC FAIL.

  if ( hdr == NULL )
  {
#ifdef HEAPMGR_METRICS
    HEAPMGR_MEMFAIL++;
#endif
  }

Now, There are about 70 Peripherals.
We can see there is no Memory Leak, but many malloc fail.
When do a Scan, HEAPMGR_MALLOC() be called about 1600 times, FAIL 800 times, FREE 800 times, as follow:

SComplete, malloc:1676, fail:859, free:787
proCur 12 9 7 0 0 0 0 2
proMax 19 54 12 0 0 0 0 2
proTot 102 116 597 0 0 0 0 2
proFai 0 422 436 0 0 0 0 1
Scan...
SComplete, malloc:3544, fail:1899, free:1615
proCur 12 9 7 0 0 0 0 2
proMax 19 54 12 0 0 0 0 2
proTot 185 171 1287 0 0 0 0 2
proFai 0 937 960 0 0 0 0 2
Scan...
SComplete, malloc:5268, fail:2832, free:2406
proCur 12 9 7 0 0 0 0 2
proMax 19 54 12 0 0 0 0 2
proTot 268 229 1937 0 0 0 0 2
proFai 0 1397 1432 0 0 0 0 3

set DEFAULT_MAX_SCAN_RES to 80, the MALLOC, FAIL, FREE times no obviously different .

SComplete, malloc:1823, fail:952, free:841
proCur 12 9 7 0 0 0 0 2
proMax 21 54 13 0 0 0 0 2
proTot 95 109 665 0 0 0 0 2
proFai 0 471 480 0 0 0 0 1
Scan...
SComplete, malloc:3479, fail:1843, free:1606
proCur 12 9 7 0 0 0 0 2
proMax 21 55 13 0 0 0 0 2
proTot 181 171 1282 0 0 0 0 2
proFai 0 908 933 0 0 0 0 2
Scan...
SComplete, malloc:5118, fail:2717, free:2371
proCur 12 9 7 0 0 0 0 2
proMax 25 55 15 0 0 0 0 2
proTot 271 226 1902 0 0 0 0 2
proFai 0 1342 1372 0 0 0 0 3

3.
By the issue and test, could we think the MALLOC times depend on the number of Peripherals but not DEFAULT_MAX_SCAN_RES?
MALLOC so many times caused the MALLOC FAIL.
While MALLOC FAIL happen, could the SDK make sure the sequence? would GAP_DEVICE_DISCOVERY_EVENT still report?
Could you please help check the issue and the SDK code?

Thanks.

Hi,

I am using peripheral + observer and i am seen the same problem only with 8 tags.

Thanks.
Ran

Hello,
How much stack/heap have you configured?
I would suggest you both profile your stack/heap usage as described in this thread:
e2e.ti.com/.../1696288

Hi Eirik,

Stack size:
#define SBP_TASK_STACK_SIZE 700

Heap size:
/* Set heap size */
BIOS.heapSize = 1668;

From this code
#include <xdc/runtime/Memory.h>
//extern const IHeap_Handle Memory_defaultHeapInstance;
Memory_Stats stats;
Memory_getStats(Memory_defaultHeapInstance, &stats);

I got:
total size is: 1664 total free size is: 408 largest Free Size is: 408
the values were constant all the time.

After i added HEAPMGR_METRICS to predifine I got:
heapmgrBlkMax is: 71 heapmgrBlkCnt is: 68 heapmgrBlkFree is: 14792 heapmgrMemAlo is: 50977 heapmgrMemMax is: 65535 heapmgrMemUb is: 2240 heapmgrMemFail is: 0

heapmgrBlkMax, heapmgrMemMax, heapmgrMemUb and heapmgrMemFail were constant.
heapmgrBlkCnt has a variaint of 10
heapmgrBlkFree is increasing every half a sec with around 3.5
heapmgrMemAlo is decreasing every half a sec with around 195 and when it reach low level it goes back up to around 65000

the last 3 massage (0.5 sec between each message) I got before the program crashed was:
heapmgrBlkMax is: 74 heapmgrBlkCnt is: 56 heapmgrBlkFree is: 43005 heapmgrMemAlo is: 49400 heapmgrMemMax is: 65535 heapmgrMemUb is: 2352 heapmgrMemFail is: 0
heapmgrBlkMax is: 74 heapmgrBlkCnt is: 56 heapmgrBlkFree is: 43008 heapmgrMemAlo is: 49264 heapmgrMemMax is: 65535 heapmgrMemUb is: 2352 heapmgrMemFail is: 0
heapmgrBlkMax is: 74 heapmgrBlkCnt is: 57 heapmgrBlkFree is: 43014 heapmgrMemAlo is: 49016 heapmgrMemMax is: 65535 heapmgrMemUb is: 2352 heapmgrMemFail is: 0

and now the program is in Hwi_excHandler.

Is there anything else you would like me to check?

Check out "9.8 Deciphering CPU Exceptions" under the "Development and Debugging "chapter in the CC2640 BLE Software Developer’s Guide (SWRU393).

Hi Eirik,

i am getting CFSR:BFARVALID set on and the address in BFAR register is: 110000000010000001000010011 (0x6010213).

execLR = 0x200037B0.

And this is happening when i try to use the variable: gapPeripheralObserverRoleEvent_t* pEvent that i get from the callback of found device.

Ran

Hello,
You can check your output MAP file to try to find the calling function from your link register. The address 0x6010213 (0x06010213) seems to be an invalid flash address as it far exceed the FLASH_SIZE address range (0x00000000-0x00020000).

Have you based your code on the CC2640 Peripheral Observer V2 1?
processors.wiki.ti.com/.../CC2640_Peripheral_Observer_V2_1

Could your issue be related to this thread?
e2e.ti.com/.../1722726

Hi Eirik,

We are getting every run different address, so looking at the map file wont help.

Yes, we have based our code on Peripheral Observer V2.1.

We have tried the solution in the post you gave us with no luck.

Another thing we tested and seen is that if we reboot every 5 mins we are not crashing.

Best,

Ran Caspi

Hi,

Please find a workaround for a bug found with the Peripheral Observer 2.1 project in this thread:
e2e.ti.com/.../1899344

Best wishes