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
From the screenshot you provided I don't see your proprietary service, only the NUS service.
Exactly. In the first screenshot, you could my service but for some reason, I no longer see it even though I reverted my changes to the older revision. Do you really why would this be?
Skipping APP_ERROR_CHECK() might not be a good idea. It won't allow you to detect if there is any error.
Oh, I thought that's what you initially meant when you mentioned "you can modify the code to ignore the NRF_ERROR_INVALID_STATE and not assert it. "
Hi Morpho,
Please do it step by step.
Step one you can try to remove the UART service in the example and flash and check what you have in the ATT table when doing service discovery. Try not to bond to the device because the phone may cache the att table and don't update it if it's bonded.
Step two you can add your own service (without any functionality) just to check if the service is listed in the att table.
After you can find it in the att table you can start implementing the code as we discussed earlier.
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?
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?