Hello,
last week I was trying to integrate a wake-on-motion-functionality for my hardware using some interrupt-handling. While that problem is solved, I came across some kind of interdependency between initializing the GPIO- and the BSP-module simultaneaously.
Here is the code of the 2 functions which I am using:
a) gpio_config()
{
ret_code_t err_code;
err_code = nrf_drv_gpiote_init();
check_error_code(__func__, err_code, 1);
nrf_drv_gpiote_in_config_t pin_config = GPIOTE_CONFIG_IN_SENSE_LOTOHI(true);
err_code = nrf_drv_gpiote_in_init(MOTION_IRQ_PIN, &pin_config, motion_irq_evt_handler);
check_error_code(__func__, err_code, 2);
nrf_drv_gpiote_in_event_enable(MOTION_IRQ_PIN, true);
printf("%s(): GPIOs initialized\r\n", __func__);
}
b) bsp_config(bool *p_erase_bonds)
{
bsp_event_t startup_event;
uint32_t err_code = NRF_SUCCESS;
err_code = bsp_init(BSP_INIT_LED | BSP_INIT_BUTTONS,
APP_TIMER_TICKS(100, APP_TIMER_PRESCALER),
bsp_evt_handler);
if (err_code != NRF_ERROR_INVALID_STATE)
{
check_error_code(__func__, err_code, 1);
}// if (err_code != NRF_ERROR_INVALID_STATE)
err_code = bsp_btn_ble_init(NULL, &startup_event);
if (err_code != NRF_ERROR_INVALID_STATE)
{
check_error_code(__func__, err_code, 2);
}// if (err_code != NRF_ERROR_INVALID_STATE)
*p_erase_bonds = (startup_event == BSP_EVENT_CLEAR_BONDING_DATA);
printf("%s(): BSP initialized\r\n", __func__);
}
c) Calling-procedure in main()
{
bool erase_bonds = true;
uint32_t err_code = NRF_SUCCESS;
system_startup();
// Initialize hmi
gpio_config();
bsp_config(&erase_bonds);
// Initialize peer-manager
pm_config(erase_bonds);
// Initialize bt-support
ble_stack_init();
gap_params_init();
services_init();
...
}
When I first started using this particular procedure with SDK v12.0.0, I was experiencing the a problem with error-code NRF_ERROR_INVALID_STATE (0x0008) inside bsp_config(). So I decided to just uncomment the functionality within bsp_config(), but then I was running into some dependency-issues regarding the ble-advertising. Then I went for a simple workaround by just excluding this error-code from being handled by APP_ERROR_CHECK(), which basically just "disguises" the error and doesnt actually solve it.
After upgrading my SDK to v12.2.0 - without adjusting anything of the code-parts a)-c) - the entire functionality within bsp_config() seems to be causing a problem, so that I actually have to uncomment all of its occurences to keep my system operational.
Now to my questions:
a) Is there any specific order in what way the initialization of the GPIO- and the BSP-module should be handled?
b) Does the upgrade from SDK v12.0.0 to v12.2.0 require any adjustment of the bsp_config()-code or the initialization-order inside main()?
I was already cross-checking with some of the SDK-examples, but the code inside bsp_config() is pretty much the same everywhere and also the call inside main(), which always happens before initializing the peer-manager or the ble-stack!
This is where I am lost...
