Using GPIOTE with S130 in the BLE UART example

RE: Using GPIOTE with S130 in the BLE UART example

Johnson — Wed, 09 Dec 2015 10:14:40 GMT

Ole, you are a champion!!

Following your suggestion, I found how to implement the priority in https://devzone.nordicsemi.com/question/57691/app_scheduler-and-timer1-hardfault/

The GPIOTE works after I added

  NVIC_SetPriority(GPIOTE_IRQn, APP_IRQ_PRIORITY_LOW);

in the initialisation step, straight after

  err_code = nrf_drv_gpiote_in_init(AUDIO_STIM_PIN, &event_config, stimulus_handler);
  APP_ERROR_CHECK(err_code);

RE: Using GPIOTE with S130 in the BLE UART example

Ole Bauck — Tue, 08 Dec 2015 15:42:58 GMT

I should have thought of this before: The GPIOTE handler is running at APP_PRIORITY_HIGH, which means that sd_ble_gattc_write(...) is called at this level. It is not allowed to do SoftDevice calls at APP_PRIORITY_HIGH, and if attempted to do so, the application will run into hardfault. SoftDevice calls have to be made in main context or at APP_PRIORITY_LOW. I will update my answer if this is correct. Sorry for the late answer.

RE: Using GPIOTE with S130 in the BLE UART example

Johnson — Sat, 05 Dec 2015 13:15:51 GMT

After pressing the button triggering my gpiote event, I could still step through the code until it reaches line 84 (below) in ble_uart_c.c.

    err_code = sd_ble_gattc_write(m_tx_buffer[m_tx_index].conn_handle,
                                  &m_tx_buffer[m_tx_index].req.write_req.gattc_params);

If I select Step Into, it goes to line 160 of arm_startup_nrf51.s

HardFault_Handler\
                PROC
                EXPORT  HardFault_Handler         [WEAK]
                B       .
                ENDP

and then it is stuck.

I also attempted to use polling. I wrote a function that sends a character to the dongle whenever button press is detected. The function is located in the for loop in the main function (below) and works fine.

for (;;)
{
    power_manage();
	stimulus_polling();
}

RE: Using GPIOTE with S130 in the BLE UART example

Ole Bauck — Fri, 04 Dec 2015 13:04:03 GMT

You should have gotten the event. You are sure the code is not stuck? Try stopping the execution while in debug after the disconnection.

RE: Using GPIOTE with S130 in the BLE UART example

Johnson — Fri, 04 Dec 2015 12:31:04 GMT

I found 2 places that have BLE_GAP_EVT_DISCONNECTED event in the project, namely,

device_manager_central.c
ble_db_discovery.c

I placed breakpoints in the switch case for this event. But when the disconnection occurred, the execution did not go to any of these breakpoints.

Any suggestion where I can detect the event?

RE: Using GPIOTE with S130 in the BLE UART example

Ole Bauck — Thu, 03 Dec 2015 13:56:06 GMT

When you step through the code, the chip will stop and the link will timeout and be lost. Also, the SoftDevice may stop working correctly and cause a hardfault. Therefore step debugging should be approached carefully. If the disconnection is not caused by an error condition you can check the disconnect reason in BLE_GAP_EVT_DISCONNECTED event, it should be in p_ble_evt->evt.gap_evt.params.disconnected.reason. If you have a spare nRF dongle or a board you can also try the sniffer to see what is going on over the air, see here.

RE: Using GPIOTE with S130 in the BLE UART example

Johnson — Thu, 03 Dec 2015 12:47:12 GMT

That's the wierd part. There was no error. The LEDs didn't lit up.

In debug mode, I could see that pressing the button switch invoked the gpiote event handler and could step through the lines. Suddenly, the red LED on the dongle went blinking - BLE was disconnected. I could still step through the code until it "froze" usually at sd_ble_gattc_write(m_tx_buffer[m_tx_index].conn_handle, &m_tx_buffer[m_tx_index].req.write_req.gattc_params); or memcpy(p_msg->req.write_req.gattc_value,p_str,p_str_len); in ble_uart_c_write_string.

So it never went to app_error_handler.

EDIT: I commented out the code in the gpiote event handler stimulus_handler. If the code is running not in the debug mode, pressing the button switch does not make the BLE link disconnected.

But if the code is running in the debug mode, the BLE link got disconnected after pressing the button.

RE: Using GPIOTE with S130 in the BLE UART example

Ole Bauck — Wed, 02 Dec 2015 13:30:06 GMT

Any error (leds lit up)? Go into debug and set a breakpoint at while(1) in app_error_handler, check the error code, line number and file variables.

RE: Using GPIOTE with S130 in the BLE UART example

Johnson — Wed, 02 Dec 2015 13:19:10 GMT

Thanks for that. I just discovered this too after stepping through in Debug.

I also decided to use another pin (P0.15) and placed another button switch there so that it will call my event handler instead of gpiote_event_handler. I also had to use the high accuracy option (nrf_drv_gpiote_in_config_t event_config = GPIOTE_CONFIG_IN_SENSE_HITOLO(true);). After these two changes and adding the init check (nrf_drv_gpiote_is_init) that you pointed out, the code worked as original.

Interestingly, when I pressed the new button, the BLE link was disconnected. The red LED on the dongle changed from on (connected state) to blinking (disconnected). I expected stimulus_handler to be executed which sent the string "A" to the dongle. If the reset button the DK board is pressed, the BLE link was connected again. But pressing the button disconnected the ink again.

RE: Using GPIOTE with S130 in the BLE UART example

Ole Bauck — Wed, 02 Dec 2015 11:46:23 GMT

Update answer:

The gpiote driver is already initialized so nrf_drv_gpiote_init() will return error and either stop the code or reset the chip depending if DEBUG is defined (see the code in app_error_handler(...)). Change to this code:

if(!nrf_drv_gpiote_is_init())
{
    err_code = nrf_drv_gpiote_init();
    APP_ERROR_CHECK(err_code);
}

Update 09.12.2015: The GPIOTE handler is running at APP_PRIORITY_HIGH, which means that sd_ble_gattc_write(...) is called at this level. It is not allowed to do SoftDevice calls at APP_PRIORITY_HIGH, and if attempted to do so, the application will run into hardfault. SoftDevice calls have to be made in main context or at APP_PRIORITY_LOW.

RE: Using GPIOTE with S130 in the BLE UART example

Johnson — Wed, 02 Dec 2015 11:19:13 GMT

When the main function called gpiote_init, the DK board did not reach scanning. All 4 LEDs were on.

Without gpiote_init, the DK board scanned and could detect the dongle board which was running the periperhal code. Only LED 1 was on.

How do I check that err_code does not return NRF_SUCCESS ?

I also discovered that if m_cb.state = NRF_DRV_STATE_INITIALIZED; is commented out in nrf_drv_gpiote_init, the code works.

I don't understand why though.

RE: Using GPIOTE with S130 in the BLE UART example

Ole Bauck — Tue, 01 Dec 2015 16:30:46 GMT

What do you mean when you say "stopped working"? Do the chip reset (this is the default behaviour if err_code is not NRF_SUCCESS in APP_ERROR_CHECK(...))?

RE: Using GPIOTE with S130 in the BLE UART example

Johnson — Sun, 29 Nov 2015 11:53:35 GMT

Never mind. I managed to get the gpiote event working though it did not respond to a LED task through ppi. That's for another question.

RE: Using GPIOTE with S130 in the BLE UART example

Johnson — Sat, 28 Nov 2015 14:20:07 GMT

Thank you for the suggestion, Ole Bauck.

I looked into the gpiote example in SDK 9.0.0. The example only used gpiote task to drive the LED while gpiote event is not included. I tried to add a gpiote event but it did not work.

Is there any gpiote example that uses gpiote event (e.g. evoked by a button switching the pin fro high to low)?

RE: Using GPIOTE with S130 in the BLE UART example

Ole Bauck — Thu, 26 Nov 2015 15:06:00 GMT

app_button does not use timer for polling in that sense. It uses a timer for a debounce delay after the button has been pushed, see here. The error you are getting is because GPIOTE_IRQHandler is defined in nrf_drv_gpiote.c and in main.c. I would suggest that you use the nrf_drv_gpiote library. Be aware that with the SoftDevice, the delay may be longer than 1 ms while in a connection, see here for more info.