RTOS/CC2640R2F: Changing Android bluetooth addresses.

Hi Rachel,

I haven't got SmartRF Flash Programmer so will not read SNV.

I have tried simple_peripheral from the same SDK and it is working well with cc2640 initiating pairing! (GAPBOND_PAIRING_MODE_INITIATE). I connect, get request for passcode, get bonded, and then DC and connect without any additional pairing requests. To be clear - I get one random address and on subsequent connection the factory one BT address. 

I have captured sniffer log for my multi_role scenario with GAPBOND_PAIRING_MODE_INITIATE and GAPBOND_PAIRING_MODE_WAIT_FOR_REQ. Android phone is always initiating a connection since it is the master here.

INITIATE:

1STinitiate.psd: Android initates the connection, gets pairing request from cc2640, inserts passcode, "bond save success", get random address

2NDinitiate.psd: Android initates the connection, gets disconnected without pairing request, get another random address

3RDinitiate.psd: Android initates the connection, gets pairing request, inserts passcode, "bond save success", get factory BT address

WAIT_FOR_REQ:

waitForReq.psd: Android initates the connection, ask for bond, insert passcode, "bond save success", click DC and connect multiple times, click "delete bond info", ask for bond, type in, "bond save success", click DC and connect, "bonding success",

I still get the real address on the 3rd connection. What could possibly be the reason for that, something in multi_role.c maybe? 

1STinitiate.psd2NDinitiate.psd3RDinitiate.psdwaitForReq.psd

Hi,

In order to make multi_role example work the way I needed (work as a peripheral and accept up to 3 simultaneous connections from masters) I have changed one definition in predefined symbols

from:

MAX_NUM_BLE_CONNS=1

to

MAX_NUM_BLE_CONNS=3.

Without this cc2640 stops advertising if one master connects to it. With the definition I am able to connect 3 smartphones. This is okay.

I have noticed one important thing: the problem with bonding I have described in the topic appears only when MAX_NUM_BLE_CONNS > 1.

When ...=1 bond save happens during the first connection (GAPBOND_PAIRING_STATE_BOND_SAVED), during subsequent connections bonding is occuring correctly (GAPBOND_PAIRING_STATE_BONDED) and I get my factory BT address.

Looks like MAX_NUM_BLE_CONNS=3 is messing with the bonding somehow. :(

Any ideas how to make bonding working properly WITH the ability to accept 3 connections at a time?

Thanks

Hi,

Any thoughts on this?

This is really urgent. I can't proceed without having this solved.

thanks

Hi pawelN,

I would recommend trying to enable HEAPMGR_METRICS to see if you are out of RAM. See the Debugging chapter of the TI BLE-Stack User's Guide for more information: http://dev.ti.com/tirex/#/?link=Software%2FSimpleLink%20CC2640R2%20SDK%2FDocuments%2FBLE-Stack%2FBLE-Stack%20User%27s%20Guide

Here is a link to download SmartRF Flash Programmer 2: http://www.ti.com/tool/FLASH-PROGRAMMER

Connect your device, go to the Edit tab, then read flash page 30 to a file to dump your SNV.

Hi, 

Thank you Rachel for response.

I thought that the SmartRF Programmer was an external device, not just a software tool. I have collected a few page30 .bin SNV dumps which I don't know how to open. I am attaching them. I believe the names for them are self explanatory and I am aware that reading SNV leads to device reset. The procedure was like that:

1- flash the device,
2- connect Android1 to cc2640 and pair,
3- disconnect Android1
4- connect Android1
5- disconnect Android1
6- connect Android1 (this is the moment when I know the  BT MAC address of smartphone1)
7- connect Android2
8- pair Android2
9- disconnect Android2
10- connect Android2
11- disconnect Android2
12 - connect Android2 (this is the moment when I know the  BT MAC address of smartphone2)

a_justFlashed: step 1, read SNV
b_firstAndroidConnectedAndBonded: step 1-2, read SNV
c_firstAndroidDisconnected: step 1-3, read SNV
d_firstAndroidReconnected: step 1-4, read SNV   
... and so on and so on...

I can't attach .bin files so I zipped them all:

New folder.zip

I will try to use HEAPMGR later on.

Can you, Rachel, or someone from TI do a simple test and just take multi_role example from sdk 1.50.0.58, change compiler predefined symbol MAX_NUM_BLE_CONNS=1 MAX_NUM_BLE_CONNS=3 and use those options for bond manager:

uint8_t pairMode = GAPBOND_PAIRING_MODE_INITIATE;

uint8_t mitm = TRUE;

uint8_t ioCap = GAPBOND_IO_CAP_DISPLAY_ONLY;

uint8_t bonding = TRUE;

uint8_t security = GAPBOND_SECURE_CONNECTION_NONE

and check how does the bonding work on cc2640? I believe it should take one reconnect to get BT MAC address, not two :(

Thanks

Hi again

I have used HEAPMGR_METRICS.  Thanks to Sean from e2e.ti.com/.../2522477 I was able to use this in multi_role.c:

static void multi_role_taskFxn(UArg a0, UArg a1)
{
  // Initialize application
  multi_role_init();

  // Application main loop
  for (;;)
  {       
      uint32_t *pBlkMax = ICall_malloc(15);
      uint32_t *pBlkCnt = ICall_malloc(15);
      uint32_t *pBlkFree = ICall_malloc(15);
      uint32_t *pMemAlo = ICall_malloc(15);
      uint32_t *pMemMax = ICall_malloc(15);
      uint32_t *pMemUB = ICall_malloc(15);
      ICall_getHeapMetrics(pBlkMax, pBlkCnt, pBlkFree, pMemAlo, pMemMax, pMemUB);

      Log_test6("heapMetrics: %d %d %d %d %d %d", *pBlkMax, *pBlkCnt, *pBlkFree, *pMemAlo, *pMemMax, *pMemUB);

        ICall_free(pBlkMax);
        ICall_free(pBlkCnt);
        ICall_free(pBlkFree);
        ICall_free(pMemAlo);
        ICall_free(pMemMax);
        ICall_free(pMemUB);

....
....
uint32_t events;
....
.... //the rest of the function

and these are the values (in decimal) I obtained:

the values may differ a little bit, but in the end maximum simultaneous allocated memory is like ~5600 bytes. Let's suppose that 3 smartphones connected to cc2640 would lead to MemMAX reaching about 6000 bytes of memory, ok?

Then I have checked the .map file and got:

0x20004000 heapEnd
0x200023b0 heapStart
----------------- difference = 0x1c50, which is 7248 bytes. I am not even close to this value so I believe I got no heap issues here. 

Was my approach correct?

Hi pawelN,

Your approach was correct but please check the heapmgrMemFail value as well when you add the third connection.

Hi Rachel,

Right now I have no access to three smartphones but I believe there is no big difference wether I use 2 or 3 smartphones (MAX_NUM_BLE_CONNS=2 and ...=3 respectively). It just has to be more than 1.
I added heapmgrMemFail to my ICall_getHeapMetrics function definition and did the tests. pMemFail was =0 throughout connecting, disconnecting, both devices connected, bonded etc so no memory allocation failures at all.


Meanwhile can you try to reproduce my bug? I am wondering if it is something with my files or the software TI provided. I am copy-pasting the method below:

* take multi_role example from sdk 1.50.0.58, change compiler predefined symbol from
* MAX_NUM_BLE_CONNS=1 to MAX_NUM_BLE_CONNS=2 or MAX_NUM_BLE_CONNS=3
* and use those options for bond manager:
uint8_t pairMode = GAPBOND_PAIRING_MODE_WAIT_FOR_REQ;
uint8_t mitm = TRUE;
uint8_t ioCap = GAPBOND_IO_CAP_DISPLAY_ONLY;
uint8_t bonding = TRUE;
uint8_t security = GAPBOND_SECURE_CONNECTION_NONE;
* print ( (char*)connHandleMap[0].strAddr ) to see address in puTTY
* flash cc2640 launchpad
* operate on the android side (for example nRF connect app): connect, bond, disconnect, connect
does the terminal show android device factory BT address after the first reconnect? Or after two reconnects?

Thanks

Hi Rachel and thanks for response

Your method is a little bit different from mine because when you use MAX_NUM_BLE_CONNS=3 there is no need to manually reset advertising with buttons in order to reconnect. I didn't do that because after first connection the device still advertises.

BUT

Now I see that disabling and reenabling advertising is needed to refresh the resolving list. Thank you for that information, this is very important to me. 

In my application after getting GAP_LINK_TERMINATED_EVENT I disable advertising, and put a clock to set event for restarting advertising after 2 seconds. Right now it seems working for both devices connected.