GAP_Connect does nothing. Why?

[brian_dodge]

GAP_Connect doesn't do anything when used to connect to a scanned bonded device. The function returns success but there is no response from the stack and no callback of any type and thus no connection. How do I debug this?

[mario_castaneda]

Hi Brian,

Could you please provide more information about your issue?

What is the device that you are working on? What is the example that you are running on?

Regards,

Mario

[brian_dodge]

QN9080C as central. Other devices as peripherals.

I scan for a service, and when found, stop scan, GAP_Pair, and go on to GATT.  This works well, and repeatably.

If the peripheral goes away, there is a disconnect event where I restart scanning,  When peripheral comes back, I stop scan and call GAP_Connect.  The peripheral is bonded at that point and GAP_Connect returns success but there is no callback and nothing sent (like connect request) on the air seen on my Ellisys. 

With some peripherals (Windows 10) the connect does work, and then GAP_EncryptLink is called which seems to work, but then GATT stalls for some reason: no errors, no callbacks, and eventually the remote side closes the connection.

[mario_castaneda]

Hi Brian,

Did you set the privacy parameter?

Are you working on the wireless UART example? Central Rol? or the HID Host example?

Look at for the event gConnEvtConnected_c 

A connection has been established. Data in gapConnectionEvent_t.eventData.connectedEvent.

The connection callback is the same as the callback used by the Central when calling the Gap_Connect function.
If a Central initiates a connection to this Peripheral, the gConnEvtConnected_c connection event is triggered.

Note: The vast majority of the GAP and GATT APIs are executed asynchronously

Regards,

Mario

[brian_dodge]

Our application is built from some of the examples. I have inherited this code base so don't know the exact origins.

I have debugged to a point where I can pair-bond with the peripheral multiple times if I don't restart the central.  If I restart the central, the connect hangs.

It seems like it might be an issue with nv-storage. At each reset, the NXP stack reads the bonded device header info out of nvram,  If I then pair/bond a new peripheral it writes the header and static bond data to nvram.  Then, in the normal reconnect case, when the NXP stack re-connects to a bonded peripheral it reads the bond info back out of nvram.

If I then reset, the headers are read out at start up (and the data looks the same as it did), but when I call GAP_Connect, there is no attempt to read the reset of the bond information.

The whitelist is populated with the bonded device info properly at startup.

[mario_castaneda]

Hi Brian,

I am assuming that you defined the gAppUseNvm_d, gAppUseBonding_d and gAppUsePairing_d.

Note: if the gAppUseNvm_d is equal to 0, the information will be saved in the RAM memory.

When you bonded a device, are you reading out the NVM Flash Memory?

If I then pair/bond a new peripheral it writes the header and static bond data to NVRAM

What is the process that you are doing to bond the devices?

Regards,

Mario

[brian_dodge]

Yes, pairing and bonding are defined (which is why it works in most cases).  We have our own nv storage so don't use the built-in mechanism, but our storage is working fine (which is why the resolvable address cases work over reset).

The pair/bond is done using just-works with the peripheral. The failing scenario now is when the peripheral uses a static address and I reset the central (NXP) device after pairing/bonding.   If I reset the peripheral, the NXP reconnects properly as long as the NXP stays up. Once reset and scanning started, the device is recognized and the GAP_Connect call is made (which returns success) but there is NO further callback and NO packets sent on the radio.

The only difference I can note in this case is that the nv storage is NOT accessed before the connect is made. In the working cases, the bond information is read from nv storage during the connect which then works.

In any case, there should never be a case where GAP_Connect is called with no effect and this has to be a bug in the stack somewhere I'd think.

[Xiang_Li]

Hi Brian,

General advice to support your debugging. First recreate the issue. Then at the moment when you call GAP_Connect() - which has no effect and no callback - replace the GAP_Connect() with a Gap_StartScanning().

Make sure the scan parameter is such that any adv packet would be picked up. And see if you got any scan callback.

Because the BLE connect and scan work similarly, they both need to put the radio into Rx mode to listen for adv packets from the peer devices. If the Gap Scan works well, then at least we know it is not hardware issue. And your QN9080 can still correctly listen BLE packets at that time.

If assuming the BLE scan works properly, then it is possible your connection parameters are wrong. If the adv devices is using resolvable addresses - meaning it is changing all the time - then I remember there is a filter policy you need to config in the connection parameters. I am not sure if we can still use whitelist for this case.

Regards,

Xiang

[brian_dodge]

This was actually caused by corrupted nvds

[brian_dodge]

Further information:  The failure occurs when the peripheral has a private (random) static address.

For peripherals with random resolvable addresses the bond works and reconnects properly.

My guess is there might be an issue with over a reset, the NXP app loses the information that the address is not resolvable and attempts to resolve it and can't but doesn't report failure up the stack, so no callback.