QN908x crash when discovering attributes by uuid

[joseraffucci]

I've encountered some strange behavior when I try and discover attributes via uuid.  I have two boards with identical QN90x MCU's (host, controller) running the same SDK.  The host contains approximately 100 attributes in the gatt db.  I am able to discover all services and attributes from gatttool as well as various other tools on my phone and tablet.  When I try and discover from the controller, I find that I get a hard fault whenever I set the service limit higher than 40 or so.

This example does not work:

bleUuid_t *myUuid =  "UUID corresponding to handle 0x29 in host db";
gattService_t dummyService;
dummyService. startHandle = 0x0001;
dummyService. endHandle = 0xFFFF;
static gattCharacteristic_t hrcpCharacteristic;
static uint8_t mcHrcpChar;
bleResult_t result = GattClient_DiscoverCharacteristicOfServiceByUuid(deviceId,
                                                                      gBleUuidType128_c,
                                                                      &myUuid,
                                                                      &dummyService,
                                                                      &hrcpCharacteristic,
                                                                      1,
                                                                      &mcHrcpChar);

If I change the endHandle to 35, it does.

The debugger catches a hard fault on the host:

I suspect I'm hitting a memory limit somewhere but it's strange that I don't see this error when I try and discover from the gatttool or do a full service discovery.  Any suggestions on what buffer I may need to increase or why there might be a difference in behavior?

[joseraffucci]

So it definitely looks like a memory issue.  I set a range breakpoint at 0x0 and found this.  It appears that somebody may have gotten stomped on.  Note the destination pointer.

I've increased every buffer I can find with no luck.  Any ideas on how to track this down? 

[estephania_mart]

Hello, 

You can try to track this down by enabling the following macros and trying to identify where are you getting this., 

#define gUsePanic_c 1
#define MEM_TRACKING
#define MEM_STATISTICS
#define MEM_DEBUG
#define MEM_DEBUG_OUT_OF_MEMORY 

Hope it helps, 

Regards

Estephania 

[joseraffucci]

Thank you, yes.  Enabling those macros helped me track down the problem.

Apparently gatttool and the ble controller stack handle the discovery requests a little differently and have different memory requirements.  In my case I did not have enough large memory blocks in my pool and it was causing the MEM allocation to fail which ultimately led the memcpy to use an invalid pointer.

Thanks again for the quick response!

[estephania_mart]

It is good that you were able to solve your issue. ! 

Regards