Force GPIOTE event manually.

[SeanHowsonTB]

Using SDK17.1.0, I need to manually force an event handler to run. But the event handler is part of the SDK and is declared static. Key constraint is that i cannot modify the SDK.

I'm using the app_button library. But the handler i registered for the button doesn't run when the chip is wakes up from shutdown mode (following button press). I am aware this is because the debounce timer doesn't start (started in the gpiote event handler).

I tried manually running my local app_button handler, but of course this skips many steps within the app_button library and causes all sorts of problems. So, essentially i need to call a function from further back in the call stack/ chain of events.

But every function that potentially provides a route to triggering the app_button event handler is declared static or is out of scope of my code.

The event handler i'd like to trigger is below: (line 245 app_button.c)

 

static void gpiote_event_handler(nrf_drv_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
    app_button_cfg_t const * p_btn = button_get(pin);
    bool is_set = nrf_drv_gpiote_in_is_set(p_btn->pin_no);
    bool is_active = !((p_btn->active_state == APP_BUTTON_ACTIVE_HIGH) ^ is_set);

    /* If event indicates that pin is active and no other pin is active start the timer. All
     * action happens in timeout event.
     */
    if (is_active && (m_pin_active == 0))
    {
        NRF_LOG_DEBUG("First active button, starting periodic timer");
        timer_start();
    }
}

Ideally i could do to find the memory location in which the pointer to the above handler is stored (when it is initialised). i could, for example, do this using the following code:

   nrfx_gpiote_evt_handler_t handler = channel_handler_get((uint32_t)channel_port_get(BTN_PIN));
         handler(BTN_PIN, GPIOTE_CONFIG_POLARITY_HiToLo);       

But again, both of these functions are static.

 

Ideally, i'm looking for suggestions of global functions that can be used to retrieve a pointer to the gpiote event handler (the one in the first extract of code above). Or some other way of manually forcing a button action. Even if i could perhaps manually force the pin's IRQ at register level?

Thanks,

Sean

[Einar Thorsrud]

Hi Sean,

May I ask why you want to call the event handler directly in the first place? What is the end goal? And can you potentially achieve the end goal in another matter (for instance by doing the same as the event handler from another function)?

Also, while I understand that in some cases you may have qualified the SDK as is and cannot change it, it seems a bit unfortunate that it leads to a the need for potentially dirty hacks. It seems counter productive if the goal of not changing the SDK is related to quality somehow.

If this really is the approach you need to use, then perhaps an alternative could be this: Read a function pointer from a specific address (for simplicity you could perhaps put it in UICR for testing, but in order to support DFU etc later it should be in normal flash). Call that function pointer when you want to call the static event handler. Then, after you have built the project, check the map file to find the address of the event handler, and write that to the location that should hold the function pointer. This could be done manually first for testing. When you get this working, you can script this so that you automatically parse the map file and modify the hex file, writing the address/pointer to the fixed location you have reserved for it.

Einar

[SeanHowsonTB]

Einar, thanks for the reply.

The goal is, as is it was in my original post. Allow the chip to enter shutdown mode. Wake up from the button press and have the button press event handler run (the handler i registered to the button when initialising the app_button).

But i've found that this does not happen because the debounce timer is never started. So i am trying to manually start the chain of events that leads to my button handler being run. I am asking about the gpiote event handler because this seems to be the first domino in the chain/ first item in the call stack, that drives the app_button library. So it seemed sensible to start from the top... I tried just calling the contents of my custom app_button handler. But the app_button library, then doesn't "know" that the button has been pushed, subsequently when the button is released, my app_button handler does not run.

the chain of events i've described, runs my custom event handler, and other functions that tell the app_button library that the button is pressed. I find it odd that i seemingly cant initialised the app_button library in the "already pressed" state... anyway, another approach might be to make sure app_button library to understand that the button is pressed. so that my handler runsproperly when the button is released, that way i could manually run my handler (which is global), once upon startup, to register the press, tell the libary the button is pressed. Then the handler will run just fine when the button is released. This is the equivilent of running all the things that would be triggered by manually calling the GPIOTE event handler as id originally proposed.

I had considered & tried copying chunks of code from the functions run as a result of the debounce timer etc. But the ones i've tried require access to global variables within the app_button library, so basically the same problem i have with calling functions... (scope!)

I take your point on not having a dirty hack. I am not a fan of dirty code so would agree here. IMHO altering the SDK counstitutes as a dirty hack (this isn't the only reason i cant change it). But the purpose of this forum post is to see if there is a non-dirty-hack solution that i'm not aware of.

If i'm being honest, while i appreciate the solution you've presented it really sounds like a long winded solution for a very simple problem. While i appreciate the out-of-the-box idea, it's really not suitable for a peice of firmware being deployed into an active product and makes automation of piplining & deployment very tricky and it could easily result in some serious errors in future, especially when trying to pass the code around multiple developers & use in multiple debugging environments.

Thanks, sorry for the long reply,

Sean

[Einar Thorsrud]

Hi Sean,

SeanHowsonTB said:

IMHO altering the SDK counstitutes as a dirty hack

You could say that. And I agree that you should try to avoid it . But in reality, the SDK does not cover all use cases even though we try to make it as generic as possible, and also, it is not bug free. So it is not uncommon to have to change the SDK code, even though it is not ideal.

SeanHowsonTB said:

If i'm being honest, while i appreciate the solution you've presented it really sounds like a long winded solution for a very simple problem.

I fully agree. But it was a suggested solution for how to call a static function without changing the code that is static, which is what you describe. I do not like that approach at all, though, as mentioned.

I see the problem with interpreting the button press when it is a wakeup source. I would consider doing this with a completely different approach, handling the startup case as a special case, and using some dedicated code to handel it without the app_button library. You could still use the app_timer (with a dedicated instance) to do the debouncing. This would involve a bit more code so perhaps not ideal, but you would not have to do any changes in the SDK, and you will not have to do any other dirty hacks.

[SeanHowsonTB]

Cant find the quote tool, to i've inserted this as code! -_-

 But it was a suggested solution for how to call a static function without changing the code that is static, which is what you describe.

Yep all reasoning here is sound & appreciate you giving a solution regardless or whether it was dirty. Had i been working in assembler, or on a platform where i perhaps had much better control over the linker i would have considered the option. but as we've both agreed, the more layers you add, the less you want to mess around with the deeper layers/foundations. Thanks for the solution regardless, an interesting thought experiment if nothing else!

Thanks for the suggestion at the bottom of your last reply. You might not be far off. I could perhaps have a special case, where we accept that for the first press and release, app_button does nothing. then begin handling things through app_button library.... or something similar to this.

Currently, my button only generates actions based on a couple of fairly specific button presses, (long, super long, and some other special criteria, way outside the realms of normal mechanical bounce)... regardless, what this means is that i have some inbuilt debounce. I was only using the app_button library because months ago, i struggled to get gpiote to work on it's own. While trying to solve this issue i've gained a deeper insight to the app_button library & it may be that i can peel back a layer and just use the GPIOTE library alone.

I appreciate you working around my requirements and appreciate the feedback, opinions & discussion. It seems you've confirmed that there isn't some "non-static" function i wasn't aware of and i'll have to take some other approach outside of app_button (special cases, or maybe just GPIOTE on it's own). Thanks for the help. I think this concludes my original query regarding functions & pointers so will mark the case closed. Have a good one.

-S