low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

WolfgangEbersbach — Thu, 10 Dec 2015 15:40:01 GMT

Ole, thanks for the reply. In the meantime I removed the entire BSP stuff, so now it should also work with the nrf_drv_gpiote, but for now I leave it as it is - with direct register access. This is a nice example how too may layers of #defines and macros can lead to code that no one can understand...

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

Ole Bauck — Thu, 10 Dec 2015 15:37:16 GMT

I am glad you found the issue, I did not know the default interrupt priority was 0 and rather thought it was 3 (APP_PRIORITY_LOW), now I learned something :).

Regarding the nrf_drv_gpiote failing, this is fixed with changing

#define GPIOTE_CONFIG_NUM_OF_LOW_POWER_EVENTS 4

In nrf_drv_config.h to a higher number (the bsp module takes 4 so none was left). I am sorry this took so long, but the guy who could help me was sick. Since it is not well documented that this macro have to be changed I will make an internal case on this.

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

WolfgangEbersbach — Tue, 08 Dec 2015 15:46:42 GMT

Jepp, RK , that's it. I set the interrupt priority to "1" ( no, no 37-letter-define used ) and it works. Thanks a lot ! So, maybe the nrf_drv_gpiote_in_init I originally wanted to use also defaults to interrupt priority 0 and thus failed ? Again, thanks to all for helping me out. Over time, the number and stupid-ness of my questions will degrade :-)

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

RK — Tue, 08 Dec 2015 15:23:38 GMT

It doesn't matter if ap_twi uses it - not that it could, if it did you'd have multiple GPIOTE_IRQHander() functions and your code wouldn't link. All that unavailable error code means is that the interrupt is unavailable because the softdevice uses it, and since we know it doesn't, it must be the other one.

Since you say you don't set the priority - that's your problem - default 0, softdevice doesn't like that. Set it to APP_PRIORITY_HI or LO or whatever the constants are. There's an sd_* function for that too, or just call the NVIC_* one

I wonder why Keil eats error codes, don't use it myself. Often feel like using Keil must be like ploughing a field with a horse, possible, but really hard work.

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

WolfgangEbersbach — Tue, 08 Dec 2015 15:16:37 GMT

RK, thanks for the comment. 1) I do not know which of the two errors is returned. 2) I do not know if GPIOTE is an available interrupt. It is by the softdevice documentation, but maybe app_twi uses it ? 3) No, I did not set the interrupt priority, at least not that I know. I'll try to find out how to set the priority and report back here.

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

RK — Tue, 08 Dec 2015 15:00:20 GMT

So if the two errors are 'interrupt not available' and 'priority not allowed', since you know GPIOTE is an available interrupt, it must be an invalid priority. Did you set the priority of the GPIOTE interrupt (if it's in the rest of the answer somewhere I apologise, I looked but didn't find it). If you didn't set it, it's by default 0 which isn't allowed.

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

WolfgangEbersbach — Tue, 08 Dec 2015 13:51:25 GMT

Ole, the SoftDevice IS enabled and works. I do get ANT+ messages "on air". Just, the GPIO ISR never fires and the reason is that sd_nvic_EnableIRQ does return an error ( I am still not able to get the return values as the debugger insists that the variable assigned to it ( usually err_code ) is "not in scope". So we are back to the original where nrf_drv_gpiote_in_init also returned an error. If you could get me some advice on how to get the returned error code, we likely could track it down better. I use Keil V5.17 and your SDK version 10 (not the Keil packs) and the ant_bpwr_tx_wheel_torque_button_s210 example code.

Aaaah, so you say I need to enable the softdevice FIRST and THEN call sd_nvic_EnableIRQ() , correct ? OK, up to now I set up the softdevice last in my main().

Nope, makes no difference. APP_ERROR_CHECK does never return if it checks the return value of sd_nvic_EnableIRQ() , no matter if I call sd_nvic_EnableIRQ() before or after softdevice setup...

according to the sofdevice documentation there is only two possible errors for sd_nvic_EnableIRQ: Interrupt not available or priority not allowed... I have the feeling "something else" is using this interrupt already.

This may help tracking it down:

GPIO20 ( which is what I used here ) looks good:

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

Ole Bauck — Tue, 08 Dec 2015 12:49:29 GMT

EDIT: If the SoftDevice is enabled, use sd_nvic_enableIRQ(GPIOTE_IRQn). If the SoftDevice is not enabled, use NVIC_EnableIRQ(GPIOTE_IRQn). sd_nvic_enableIRQ(...) will return error code if SoftDevice is not enabled.

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

WolfgangEbersbach — Tue, 08 Dec 2015 10:59:23 GMT

I DO use a softdevice. You mentioned that 19 hours ago...

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

WolfgangEbersbach — Tue, 08 Dec 2015 10:45:32 GMT

Well, now it COMPILES but the sd_nvic_EnableIRQ(GPIOTE_IRQn); crashes the application.

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

Ole Bauck — Tue, 08 Dec 2015 10:16:40 GMT

You only need to use sd_nvic_enableIRQ(...) if you are using a SoftDevice. If you are not using SoftDevice, use NVIC_EnableIRQ(...) instead.

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

WolfgangEbersbach — Tue, 08 Dec 2015 09:41:48 GMT

Oooh, Ole, now I really must admit that I was very, very stupid. Putting you register access code into a function magically :-) makes it compile.. If I ever meet you in person, I owe you several beers... Lots !

The only thing remaining now is that sd_nvic_enableIRQ() is not known and I cannot find it anywhere with a "search project". So, likely it is in some .h that I have not yet included.. Yepp, in "nrf_soc.h" , found it.

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

Ole Bauck — Mon, 07 Dec 2015 15:10:03 GMT

The code I gave you does not depend on the SDK, this only depends on the register definitions defined in nrf.h (or more precisely nrf51.h) just like in AVR. I do not know what the compile error is, as I tested it before I posted it.

I forgot that you where using SoftDevice, then you should use sd_nvic_enableIRQ(GPIOTE_IRQn) instead if the SoftDevice is enabled. This is because the SoftDevice blocks the access to this register (see SD specification part 10.3).

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

WolfgangEbersbach — Mon, 07 Dec 2015 14:57:25 GMT

Hi Ole,

I removed nrf_drv_gpiote.c and as a consequence I also had to remove bsp.c, bsp_btn_ant.c, app_button.c and to comment out a lot of other stuff. Then, I at least could compile and run without the nrf_drv_gpiote.(c/h). NOTE: edited to remove wrong assumptions from my side which made this discussion confusing.

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

Ole Bauck — Thu, 03 Dec 2015 16:10:08 GMT

You can use register access on most of the peripherals, see here for which are restricted or blocked for s130 (for other SoftDevices see own specification on PDF).

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

WolfgangEbersbach — Thu, 03 Dec 2015 15:48:20 GMT

Ole, thanks. So far I got the impression that if you use a softdevice you should NOT use direct register access. Anyhow, I'll try. If I remove nrf_drv_gpiote.c, I will get 254E12 compiler errors from app_button, bsp, bsp_btn_ant and so on. I'll try.

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

Ole Bauck — Thu, 03 Dec 2015 15:37:55 GMT

I will not get an answer before tomorrow. When it comes to gpiote, you may be better off using the registers and not the SDK. This code will setup a pin for SENSING and enable the PORT event interrupt:

NRF_GPIO->PIN_CNF[BSP_BUTTON_0] =   (GPIO_PIN_CNF_DIR_Input << GPIO_PIN_CNF_DIR_Pos)
                                    |(GPIO_PIN_CNF_INPUT_Connect << GPIO_PIN_CNF_INPUT_Pos)
                                    |(GPIO_PIN_CNF_PULL_Pullup << GPIO_PIN_CNF_PULL_Pos)
                                    |(GPIO_PIN_CNF_SENSE_Low << GPIO_PIN_CNF_SENSE_Pos);

NRF_GPIOTE->INTENSET = (GPIOTE_INTENSET_PORT_Enabled << GPIOTE_INTENSET_PORT_Pos);

NVIC_EnableIRQ(GPIOTE_IRQn);

The interrupt code will be like this:

void GPIOTE_IRQHandler(void)
{
    if((NRF_GPIOTE->EVENTS_PORT == 1) &&
        ((NRF_GPIOTE->INTENSET & GPIOTE_INTENSET_PORT_Msk) != 0))
    {
        NRF_GPIOTE->EVENTS_PORT = 0;
       //code to execute on PORT event goes here
    }
}

Be sure to remove the nrf_drv_gpiote.c file from your project or you will get multiple definitions of the IRQHandler. I suggest that you also read the Reference Manual.

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

WolfgangEbersbach — Thu, 03 Dec 2015 15:06:32 GMT

It does NOT work for me with high accuracy. Note: not the nrf_drv_gpiote_in_init crashes the application. The subsequent APP_ERROR_CHECK does. So far I was not able to find out what APP_ERROR_CHECK does. It points to a function ( via a macro pointing to a macro pointing to a function ... ) that to me seem just to copy some parameters to new variables with a m_ prefix and then go to an infinite loop ?? On the debugger screenshot below you can see that "err_code" is "out of scope" ?

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

Ole Bauck — Thu, 03 Dec 2015 14:57:15 GMT

It works when setting the accuracy to high, GPIOTE_CONFIG_IN_SENSE_LOTOHI(true), strange...

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

Ole Bauck — Thu, 03 Dec 2015 14:55:27 GMT

I get the same error (NRF_ERROR_NO_MEM) just trying to add gpiote in pin in the ble_app_template example. The problem is that it should work when setting accuracy to low (will use PORT event which have no restrictions other than number of pins used). I will talk with the developers.

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

WolfgangEbersbach — Thu, 03 Dec 2015 14:28:58 GMT

Hi Ole,

I put in the "initialize only if not yet done" code with no change. The nrf_drv_gpiote_in_init fails. It also fails if I assign a different pin ( I used Button_3 before and this likely is already taken by the BSP ?? ). So, seems like there is no channel available. I try to un-assign a button from the example code to gain a channel back ? It's not documented what the buttons do, anyway..

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

Ole Bauck — Thu, 03 Dec 2015 13:16:25 GMT

Thats why the code i sent in the previous comment checks if it is initialized, and only inits it if not. It should have been called if you used app_button.

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

WolfgangEbersbach — Thu, 03 Dec 2015 12:28:43 GMT

Well, that is exactly the point: I do not know if nrf_drv_gpiote_init was called SOMEWHERE. But likely it was, as the app_button seems to use it, right ?

Anyhow, I'll now try to make an outline about who initializes what to which state where. On paper.

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

Ole Bauck — Thu, 03 Dec 2015 10:30:37 GMT

You have called nrf_drv_gpiote_init()? Do it like this:

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

RE: low power pulsewidth measurement: PPI & lfclk & S210 - some guidance needed

Ole Bauck — Thu, 03 Dec 2015 10:28:06 GMT

nrf_drv_gpiote_in_init(...) returns error? It looks like this happens either if the pin is in use by the GPIOTE already - NRF_ERROR_INVALID_STATE, or if there are no available channels (limited to 4) - NRF_ERROR_NO_MEM. Could you check the return value?