4 Replies Latest reply on Jun 21, 2018 11:23 AM by e.pratt_1639216

    Can't get GATT write "command complete" to send

    user_372477230

      Hi All,

       

      I've gone through the forums, youtube videos, and the 100 days of PSOC samples to figure this out, and am stuck.  I can't get the "command complete" event to send from my peripheral back to central, and don't know why.  I handle CYBLE_EVT_GATTS_WRITE_REQ, update the GATT DB, and call CyBle_GattsWriteRsp -- but the command complete event never gets sent.  I've tried variations in the order, changing the gatt parameters, adding in additional calls to CyBle_ProcessEvents, or even putting in random delays -- yet it never works.  I attached a debugger to the Cypress sample code, and literally looked at each call linearly, and made the same calls on my own -- yet the response is still not sent.

       

      Here's the code link to an example program I made up to show what I expect to work:

      https://github.com/ipeerbhai/PSoCBLETExperiments/blob/master/ReadWriteLED/ReadWriteExperiment/ReadWriteGATT.cydsn/main.c

       

      Line 100 is where I handle the Write Request.  Any ideas on why this doesn't send back the response I expect would be welcome.  The repo should clone and build on the BLE Pioneer kit.

       

      Thanks!

        • 1. Re: Can't get GATT write "command complete" to send
          e.pratt_1639216

          The documentation with the CyBle GattC Write command lists all of the events and response generated by it, as well as a quick summary of how they are handled. (You can see this by opening the API documentation for the BLE component, or doing a search-all for the function name).

          Also, the CYBLE_EVT_GATTS_WRITE_REQ event should have documentation associated with it in the same way as I mentioned above about what parameters and values are needed/handled/should be replied.

          • 2. Re: Can't get GATT write "command complete" to send
            user_372477230

            I've already read the docs before asking.  The sample code I linked shows what should work according to everything in the docs and the Google.

             

            Here's the code snippet I expect to work:

               case CYBLE_EVT_GATTS_WRITE_REQ:
               // Get the write request event parameters
              wrReqParam = (CYBLE_GATTS_WRITE_REQ_PARAM_T*) eventParam;
              
               // see if the host wanted to write a new should blink flag
               if ( wrReqParam->handleValPair.attrHandle == CYBLE_LEDSTATE_ISBLINKING_CHAR_HANDLE )
              {
              g_shouldBlink = wrReqParam->handleValPair.value.val[0];
               BlinkTheLED();
               UpdateGATTDBWithLedState();
               CyBle_GattsWriteRsp(g_bleConnectionHandle); // Send a response.
              }
               break;

             

            Attaching the debugger shows the Ble Handler getting called.  The LED updates correctly based on what's written by Cysmart.  The GATTDB state is correct, as I can read the db later. But CySmart times out on the write request with this code -- yet works correctly with the PSoC 100 days code sample, "Day003_Custom_Profile_CapSense_RGB_LED".  I'm making the same calls in the same order as the sample.  It should just work.

            • 3. Re: Can't get GATT write "command complete" to send
              user_372477230

              Aha!  I figured out the error.  It was something stupid.

               

              I can't call CyBle_GattsWriteRsp with my own generated handle.  I have to use the BLE generated handle!  The correct code must read:

              CyBle_GattsWriteRsp(cyBle_connHandle);

               

              It works now!! Yay!

              • 4. Re: Can't get GATT write "command complete" to send
                e.pratt_1639216

                Yeah, unless you have a need not to use the cypress variables, it is easier with only one possible BLE connection to leave all of the data/variables directly referenced.

                 

                Glad you found the problem though