Problem using GPIO- and BSP-module simultaneously

[Ray Breslin]

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...

[Ray Breslin]

Thats precisely my problem!

I did comment out everything related to GPIOTE and wake-on-motion, but I am not seeing any error-message at all... It is that just nothing happens after bsp_config() - no log output, just nothing!

Here is also my check_error_code()-function:

void check_error_code(const char* function_name, uint32_t err_code, int8_t err_position)
{
	#ifdef DEBUG_APP_ERROR_CODE
		if (err_code != NRF_SUCCESS) {
			printf("%s(): Error '%#04lx' [%d]\r\n", function_name, err_code, err_position);
		}// if (err_code != NRF_SUCCESS)
	#endif /* DEBUG_APP_ERROR_CODE */

	APP_ERROR_CHECK(err_code);
}

[Ray Breslin]

I even added additional log-messages inside bsp_config() - one before bsp_init() and one more directly after bsp_btn_ble_init(), but before the previous "initialized"-message posted above. While the first one is displayed normally, the 2nd is also displayed but without the "initialized"-message afterwards!

[Jørn]

I see you enable the timer at the end of the timer_clk_init function. This is not optimal as the timer could potentially trigger events while your system is still running inits. Enabling timers is one of the last things you should do before entering your main while loop. Just to be sure it is not interfering with anything, could you try moving the timer enable to after all initialize functions are run?

[Ray Breslin]

Well I actually do need the timer_clk to be initialized first, since I do want to have reliable timestamps for my log-messages and that was never a problem before! But I tried it as you said and it just made the entire situation worse, so that the log-output showed everything till the 2nd additional log-message in bsp_config() and then I even got a reset, which keeps repeating on the same spot everytime. It has to be something within bsp_config() because without it everything else runs fine, except the advertising...

[Jørn]

It is quite likely the timer has nothing to do with your errors, I just want to eliminate any possibility to be sure. What happens if you comment away the bsp_btn_ble_init function? Any change in behavior?