In examples\ble_peripheral\ble_app_hts, how to make sure calling order?

[faithself]

Thanks in advanced. The peripheral platform is nrf52832, sdk17.0.2. I'm migrating examples\ble_peripheral\ble_app_hts to read temperature value. When I run this example alone, I add prints and get below traces and example works well:

 0> <info> app_timer: RTC: initialized.
 0> <info> app: Health Thermometer example started.
 0> <info> app: Fast advertising.
 0> <info> app: ble_hts_on_ble_evt() is run.
 0> <info> app: Connected.
 0> <info> app: ble_hts_on_ble_evt() is run.
 0> <info> app: ble_hts_on_ble_evt() is run.
 0> <info> app: ble_hts_on_ble_evt() is run.
 0> <info> app: pm_evt_handler() is run.
 0> <info> app: pm_evt_handler() is run.
 0> <info> app: ble_hts_on_ble_evt() is run.

I notice there is something different that only you read temp value, pairing window jumps out. But after migrating, the temperature value is always 0. I notice requirement in pm_evt_handler, it says: "NOTE: For this to work, make sure ble_hts_on_ble_evt() is called before pm_evt_handler() in ble_evt_dispatch()". But I'm not clear how to ensure this. So would anyone tell me the mechanism?

[Einar Thorsrud]

Hi,

What do you mean by migrating in this context? Can you share your modified example so that I can test on my side?

Regarding the comment that is no longer valid, and should have been removed. There is no ble_evt_dispatch() function in the example in recent SDK version, as now the dispatching is handled by the SoftDevice handler library, and all modules that need BLE events register for that. (The order in which the even handlers are called in this case depend on the order in which the linker processes the object files).

[faithself]

Thanks for reply. Sorry, I can't share my company's code. About " (The order in which the even handlers are called in this case depend on the order in which the linker processes the object files)", would you please explain in detail? 

pm_evt_handler() is called below:
static void peer_manager_init(void)
{
......

    err_code = pm_register(pm_evt_handler);
......
}

ble_hts_on_ble_evt() is called due to macro:
#define BLE_HTS_DEF(_name)                                                                          \
static ble_hts_t _name;                                                                             \
NRF_SDH_BLE_OBSERVER(_name ## _obs,                                                                 \
                     BLE_HTS_BLE_OBSERVER_PRIO,                                                     \
                     ble_hts_on_ble_evt, &_name)

I can't find the clue between this two calling.

[Einar Thorsrud]

Hi,

faithself said:

About " (The order in which the even handlers are called in this case depend on the order in which the linker processes the object files)", would you please explain in detail? 

Unlike old SDKs (for which the comment you referred to was relevant), new SDKs use a mechanism where modules that need SoftDevice events register for that using the NRF_SDH_BLE_OBSERVER macro, and the events are dispatched to all registered handlers by the SoftDevice handler library. So for BLE events you can see how this is dispatched by nrf_sdh_ble_evts_poll() in components\softdevice\common\nrf_sdh_ble.c, and the order is given by the order of the section sdh_ble_observers. Section variables is a somewhat obscure but very useful mechanism which allows this list to be populated link time. See the nRF section variable documentation for details.