Peripheral Device interrogation sometimes gets stuck on CYBLE_EVT_HCI_STATUS

[Anonymous]

I have a PRoC (CYBLE-022001-00) project with two significant problems:

   

1. Interrogation frequently gets hung with the state machine apparently getting stuck on CYBLE_EVT_HCI_STATUS

   

I am tracking the BLE event / event param on an LCD during connect. I see it cycle through 44:4, 4:4, then 4c:4 when successful. But when it gets 'stuck', the central (an iOS or Android device) is unable to discover services and the state machine is on 4:4, which I believe is CYBLE_EVT_HCI_STATUS with an error code. Why would this be, and how can I make it recoverable?

   

I can easily replicate it by connecting, staying connected for a few seconds to make sure discovery completes and characteristics are being read and written to, then disconnecting. I wait a bit to ensure it returns to advertising (26:0) then reconnect. About every 3rd or 4th time it will get hung up like this.

   

2. Following disconnect, it does not always properly detect disconnect and re-start advertising. I have even had to power cycle the hardware to get it working again.

   

Has anyone else run into these issues? I do have current support tickets with Cypress as well, so I will report back if I hear anything from them.

   

Cheers all!

[GauravS_31]

Can you please attach your project for analysis? What is the error code from CYBLE_EVT_HCI_STATUS?

[Anonymous]

Hi @grsr, thanks for asking. I'm still having trouble. I am able to connect, interrogate, and communicate much of the time. But about every 3rd time I get stuck on CYBLE_EVT_HCI_STATUS with error code 4. Oddly, even when it works it always cycles through CYBLE_EVT_HCI_STATUS with error code 4 before progressing to 0x4c (CYBLE_EVT_GATTS_WRITE_REQ). But when it's stuck it never goes further than CYBLE_EVT_HCI_STATUS:4.

   

My workspace is attached to MyCase #00274530, please take a look. I will upload an updated archive now in case it exposes anything useful. You won't be able to test exactly as I do since the characteristic notifications are driven by proprietary messages originating from UART messages that come from the main processor. However, the one hint I can provide is that I never get stuck on CYBLE_EVT_HCI_STATUS when I comment out the call to CyBle_GattsNotification in the sendSPINotification method.​

   

Thank you again.

[Anonymous]

I happened to check the event coming from the stack since it is 32-bit and I am casting it to 8-bit for diplay. It turns out the event code is not actually 0x4 (CYBLE_EVT_HCI_STATUS) but instead 0x104, a value beyond the CYBLE_EVENT_T enumeration (greater than CYBLE_EVT_MAX which is 0xff)! It hits this every time I am interrogating the device following connect, and this is the last seen event when it hangs and interrogation fails. Disconnecting, then reconnecting tends to "fix" it when this happens (obviously not good enough to ship in a real product).

   

Any ideas? Why would I be seeing 0x104, a value which should be impossible?