Debugging techniques: adding custom profile/services

[Richard von Lehe]

I've got something put together akin to the ble_lbs demo which uses a custom service. In fact, it's merely the LED part of that ble_lbs service, but on custom hardware. I can discover the device just fine, but the MCP log shows that it can't read the handle 0xB when it's going through the list of attributes.

I'm attaching the screenshot that shows the data returned from the discovery and the log data as well.

I'm not sure what the 0xB handle corresponds to. I'm also a bit fuzzy on what gets created automatically vs what you must specify when it comes to descriptors within a service. Any advice on debug techniques or common gotchas is helpful.

Thanks

MCP-errors.PNG

[Ole Morten]

In general, I'd strongly recommend you to remove the reset from app_error_handler() and either uncomment the call to ble_debug_assert_handler() or insert an infinite loop of your own there, to make it easy to catch errors coming from the APP_ERROR_CHECK()s. This will enable you to halt with a debugger and inspect in which file and on which line things failed, making it much easier to find problems. You can also consider having a printf() before the infinite loop, to be able to easily log what's failing, even when not debugging.

In your particular case, it could seem as if the device fails on something and then does a reset. When you use Master Control Panel, you can click through the attributes and see the handle for them right next to the UUID, above the value field. This should help you understand which attribute it can't read. However, beware that not all attributes have to be readable, so MCP not being able to read an attribute is not in itself a problem. In this case there seems to be some problem, since the link is lost right afterwards.

One common gotcha when adding more services, if using the bond manager, is that you have to set the number of CCCDs in the bond manager configuration (ble_bondmngr_cfg.h), to make sure that buffers are sized correctly. The easiest way to count CCCDs is simply to use MCP. You don't have to take the Service Changed CCCD into account, so for the applicaiton from the screenshot, it would be sufficient to set BLE_BONDMNGR_CCCD_COUNT to 1.

Edit: If the handle that fails reading is a CCCD, what happens is most likely that the application doesn't reply to the event BLE_GATTS_EVT_SYS_ATTR_MISSING. The softdevice will give this event to ask the application to supply CCCD values for the currently connected Central. If your application uses the bond manager, this is handled there, but if not, you'll have to make sure to reply in your application. By default, if you don't ever store any information about your peer devices, this can be done by a call like this in on_ble_evt() of main.c:

        case BLE_GATTS_EVT_SYS_ATTR_MISSING:
            err_code = sd_ble_gatts_sys_attr_set(m_conn_handle, NULL, 0);
            APP_ERROR_CHECK(err_code);
            break;

Adding a print of the events you get from the softdevice may often also be a useful debugging technique, to see what's going on.

[Richard von Lehe]

Actually, I take it back. It appears to be working. The only significant change was the handling of the BLE_GATTS_EVT_SYS_ATTR_MISSING event. Sometimes I have to step back, flash everything with NRFGO, and then disconnect the JLink. I've found that Eclipse at least introduces some funky behavior at times. Without any SWD debug in the loop, this appears to run fine. I can read and write my LED characteristic after successfully discovering services.

Thanks for the help.