The application seems to stop at an instance where I invoke a Send call to send data over to a ble central, and the callstack looks as follows. Any way to narrow down the cause?
I tried the program later and I got the following stack. Thing is: nothing useful gets printed in the debug console
Hi Morpho,
It looks like it got an assertion and app_error_handler () was called.
If you haven't, please include DEBUG in the preprocessor symbols in project setting. You can add a breakpoint inside app_error_handler and check which file name, which line of code and which error code was returned.
the filename: 0x0003a1dc, error code: 8, line number: 63
Sir, I just don't understand how's UART service even being initialized when i'm not even doing so in my code? Or maybe if you could point me to a specific point in the code that shoud really tell whether UART service is being used or not. In the first screenshot you can see the custom service that's initialized. Just not sure how i'm no longer seeing it.
that's what I have.
I do see my service under Advertised Services however not quite under Attribute Table
#define CUSTOM_SERVICE_UUID_BASE {0xBC, 0x8A, 0xBF, 0x45, 0xCA, 0x05, 0x50, 0xBA, \
0x40, 0x42, 0xB0, 0x00, 0xC9, 0xAD, 0x64, 0xF3}
ble_uuid128_t baseUuid = {CUSTOM_SERVICE_UUID_BASE};
errorCode = sd_ble_uuid_vs_add(&baseUuid, &pSrvInfo->uuidType);
Hi,
Please be aware that the advertising data and the attribute table may not be related. They are belong to two different profiles and is configured independently.
What you add to advertising packet is only for advertising/connecting and has nothing to do when you are connected.
What is added to the attribute table is with these call sd_ble_gatts_service_add and sd_ble_gatts_characteristic_add
Please have a look at this guide
the advertising data is only useful when the peripheral is connected to the central though no? is sending data when the peripheral isn't even connected any good? but just advertising a base UUID has nothing to do with connection; from what I understand, it just allows the central to see the advertised peripheral in the scan list.
and you only see the attribute table after the connection is established, and i'm indeed using my custom service characteristics which are passed to sd_ble_gatts_characteristic_add as well as sd_ble_gatts_service_add for adding a custom service.
Are you fully certain it has nothing to do with the nRF Connect app which has previously been found to be buggy?
It indeed was the issue with the nRF Connect app as I had imagined. There was no my custom service wouldn't initialize and rather something that I wasn't initializing (NUS) would get picked up...for some reason.
why is the length supposed to 2 here though when looking for CCCD handle?
if ( (p_evt_write->handle == pCust->rxCustomValueHandle.cccd_handle) && (p_evt_write->len == 2))
There is a chance that the phone cached the ATT table (so that it doesn't need to do service discovery every time you connect to it) and it explain why you see the older version of the Att table.
The way to avoid that is to have SERVICE_CHANGED characteristic in the Att table. It's to tell the phone not to cache the att table. You can do that by enabling NRF_SDH_BLE_SERVICE_CHANGED in sdk_config.h
There is a chance that the phone cached the ATT table (so that it doesn't need to do service discovery every time you connect to it) and it explain why you see the older version of the Att table.
The way to avoid that is to have SERVICE_CHANGED characteristic in the Att table. It's to tell the phone not to cache the att table. You can do that by enabling NRF_SDH_BLE_SERVICE_CHANGED in sdk_config.h
thanks. I'll try.
Can you also please answer my latest question?
Sorry I forgot to answer the 2nd question. By spec the CCCD characteristic is 2 bytes, even though only the last byte is used so usually to enable notification you need to write 0x0001 and to enable indication you do 0x0002.