led_softblink on NRF_P1 affecting an NRF_P0 GPIO

[ANewman]

Hi All

First post! (be gentle!)

I'm developing on the nRF52840 and I am experiencing an issue using the led_softblink library.

I have the led_softblink configured to use P1.00. The LED on P1.00 blinks as desired.

Separately, I'm using P0.00 to sense a discrete input value (just boolean high/low). Without the led_softblink module this works as intended. Note that I'm using the internal RC and not the external XTAL, making P0.00 and P0.01 available for general GPIO.

The issue I'm having is that when I initialise the led_softblink module it is interfering with the pin configuration on P0.00 too, meaning that I can no longer sense the input on P0.00.

Config parameters for the led_softblink module:

#define M_LED_SOFTBLINK_PARAMS                                      \
{                                                                   \
    .active_high        = true,                                     \
    .duty_cycle_max     = 255,                                      \
    .duty_cycle_min     = 0,                                        \
    .duty_cycle_step    = 12,                                       \
    .off_time_ticks     = 10500,                                    \
    .on_time_ticks      = 10500,                                    \
    .leds_pin_bm        = BIT_0,                       \
    .p_leds_port        = NRF_P1                           \
}

Snippet where I initialise the led_softblink module:

    if (false == b_status_is_blinking)
    {
        APP_ERROR_CHECK(led_softblink_init(&led_sb_init_param));
        APP_ERROR_CHECK(led_softblink_start(STATUS_LED_BITMASK));
        b_status_is_blinking = true;
    }

Initialisation of GPIO P0.00 is done via:

nrf_gpio_cfg_input(NRF_GPIO_PIN_MAP(0, 00), NRF_GPIO_PIN_NOPULL);

If I manually re-configure the GPIO on P0.00 immediately prior to reading it, I get the correct value.

If I do not initialise the led_softblink module then the GPIO on P0.00 works fine too.

The led_softblink module is configured to use P1.00 and, when initialised, it is modifying the configuration of P0.00 in some way. I do not expect this.

Is this possibly a defect in the led_softblink library? My suspicion is that there's possibly a function within either the led_softblink or low_power_pwm libraries that is not factoring the port number, which is working fine for P0 but not for P1.

Any help would be appreciated.

[Kenneth]

The common problem is that P00 and P01 is in use by the 32kHz crystal, do you experience the same problem when using P01 or P02 for instance?

Anyways, did you change CLOCK_CONFIG_LF_SRC to 0 in sdk_config.h? Maybe you can read out the clock source from NRF_CLOCK->LFCLKSRC?

Also, does the same problem happen if led_softblink use P1.01?

Lot of questions, just trying to narrow down possible causes.

My suspicion is that there's possibly a function within either the led_softblink or low_power_pwm libraries that is not factoring the port number, which is working fine for P0 but not for P1.

Sounds plausible yes.

Kenneth

[ANewman]

Thanks for replying.

If I change the allocation of my blinking status LED from P1.00 to P1.01 then my GPIO function on P0.00 works normally and is not affected by the led_softblink module. Reverting the status LED to P1.00 breaks the GPIO on P0.00 again. On my hardware I'm not currently able to test whether P0.01 was affected in the same way P0.00 was.

Correction to my original post - I am using the Synth clock source and not the RC, as power consumption is not critical in my application. To test out if there's a difference I tried setting the LF clock source to the RC oscillator (value 0) and back to Synth (value 2) and the results were the same in both cases.

From sdk_config.h:

#define NRFX_CLOCK_CONFIG_LF_SRC 0

#define CLOCK_CONFIG_LF_SRC 0

or

#define NRFX_CLOCK_CONFIG_LF_SRC 2

#define CLOCK_CONFIG_LF_SRC 2

The behaviour with either of the configurations above is the same. The fault with led_softblink persists in both cases.

I have also been able to confirm that assigning the status LED, and therefore the led_softblink module, to P1.04 breaks the GPIO on P0.04 too.

[Kenneth]

Unfortunately I don't have time at the moment to recreate this myself, but I agree with your assessment that it seems that something is not taking into account the port number that is supplied. Maybe you can try to do some stepping in code while monitoring the NRF_GPIO->PIN_CNF[0] register, and you may slowly narrow down which part of the code that is doing something with this register.

Kenneth