Understanding GPIOTE better

RE: Understanding GPIOTE better

erltot — Thu, 12 Jan 2017 11:30:43 GMT

Yes. Thank you :)

RE: Understanding GPIOTE better

Hung Bui — Thu, 12 Jan 2017 11:24:54 GMT

Hi Erltot, so the issue is fixed ? A small tip, if you define DEBUG or add DEBUG into the C/C++ preprocessor symbols, and add a breakpoint inside app_error_fault_handler(), you can find out the line number and the filename of the code that caused the issue inside "info". Error code 8 meaning NRF_ERROR_INVALID_STATE. Matched with what you figured out.

RE: Understanding GPIOTE better

erltot — Thu, 12 Jan 2017 11:11:30 GMT

It seems this problem has nothing to do with SPI but rather that nrf_drv_gpiote_init() got called twice, m bad.

RE: Understanding GPIOTE better

erltot — Thu, 12 Jan 2017 10:27:52 GMT

in app_error_weak.c, __WEAK void app_error_fault_handler(uint32_t id, uint32_t pc, uint32_t info)

I get error code 8 when trying to init gpiote 0x20006BD8

my gpiote init function looks like this, call it for the pin used for external detection, and again for SPI MISO pin

static void gpio_event_init(uint8_t pin, nrf_gpio_pin_pull_t pullcfg, bool enable){
    ret_code_t err_code;

    err_code = nrf_drv_gpiote_init();
    APP_ERROR_CHECK(err_code);

    nrf_drv_gpiote_in_config_t in_config = GPIOTE_CONFIG_IN_SENSE_HITOLO(false);
    
    in_config.pull =  pullcfg;
    err_code = nrf_drv_gpiote_in_init(pin, &in_config, in_pin_handler);
    APP_ERROR_CHECK(err_code);
    if(enable) nrf_drv_gpiote_in_event_enable(pin, true);
}

If I comment out the initialization of the SPI MISO pins call, I get no errors

RE: Understanding GPIOTE better

Hung Bui — Thu, 12 Jan 2017 09:51:29 GMT

Please describe the issue you have. As I mentioned, there is no return from nrf_drv_gpiote_in_event_enable(pin, true); / nrf_drv_gpiote_in_event_disable(pin); , how and where could you get NRF_ERROR_INVALID_STATE ? I don't think you need to do anything else beside nrf_drv_gpiote_in_event_disable() to disable interrupt for that pin.

RE: Understanding GPIOTE better

erltot — Thu, 12 Jan 2017 09:05:14 GMT

Hung Bui: I still have some issues with the SPI communcation; As I wrote in bullet point 4 above, MISO needs to have interrupt attached for a short time until the peripheral pulls it low to indicate it is ready, It seems like switching between interrupt and SPI functionality on the same pin creates some problems. Do I completely have to disable the modules or something?

RE: Understanding GPIOTE better

erltot — Fri, 06 Jan 2017 13:47:41 GMT

Yes, you are right :) Thanks

RE: Understanding GPIOTE better

Hung Bui — Fri, 06 Jan 2017 13:43:31 GMT

I think you need to get to know the way BLE works. You can have a look here.

The BLE connection is kept by the central periodically send one packet and expect the peripheral to receive and send a packet back, just so both sides know that the other is still there and acknowledge. We call this connection events. Connection events happen periodically, even when there is no data or command need to be transmitted (except for Slave latency period).

So, in our implementation of the softdevice, the CPU is already enter sleep mode between connection event and wakeup every connection event. The CPU will receive any data from the central. You can catch the event caused by BLE, it's usually in on_ble_evt(). The list of event can be found in ble_gap-h, ble_gatt.h, etc.

RE: Understanding GPIOTE better

erltot — Fri, 06 Jan 2017 13:07:19 GMT

Hi Hung and thanks for your reply.

I use the interrupt to detect an external event that is not supposed to happen until the device is connected to a BLE master.

I mean sleep with keeping the connection with the master.

If I need to wake it from deep sleep, do I need a button or similar, or is there a way to wake it from a BLE event?

RE: Understanding GPIOTE better

Hung Bui — Fri, 23 Dec 2016 11:57:21 GMT

Hi Erltot,

Please be noted that you can always use the register directly if needed. The driver we provided in the SDK is just for your convenience, covering board use cases.

But I don't see any reason the driver is not suitable for your need.

I'm not sure I fully understand your description. Why do you have to set an interrupt when the device is paired ? Is paired meaning connected ? What exactly is "going to sleep" ? It's deep sleep mode or simply put CPU to sleep and keep the connection

nrf_drv_gpiote_out_init() is to configured a pin as OUTPUT and if there is a task configured for the pin. This is not related to input pin.

I don't understand this " Is there only certain things that can be done inside the in_pin_handler event? Should I instead go for setting flags and do the handling in the main loop?"

You can do what ever you want in the interrupt handler, but you will block other activity with same priority level when you are inside the interrupt handler.

If you are using the driver, you don't have to access the register directly, simply call nrf_drv_gpiote_in_event_disable(pin) will disable that pin's interrupt.

nrf_drv_gpiote_in_event_enable() won't return anything, how could you get NRF_ERROR_INVALID_STATE ?

You can use same interrupt handler for different pin (then you would need to check which pin causing the interrupt in the argument), or you can use different handler for each pin interrupt.