This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Old GPIOTE bug on softdevice S140 7.0.1

Hello, I am using nRF52840, SDK v16.0, mesh SDK 4.2.0 and softdevice S140 7.0.1. I am following this example to experiment PA/LNA features, namely controlling the pins that enable TX and RX in a front-end radio amplifier.

What happens is that I am able to check pins of port 0 being switched on and switched off automatically by the softdevice, but when I try to use any pin from port 1, it does not work.

I found that this bug happened before and was fixed on softdevice 6.1.0 by reading the release notes, but I am worried that it is happening again on 7.0.1. Are you able to reproduce this bug using the light switch server project as in the example?

Thank you,

Rúben Marques

  • Hi, 

    This is fixed in SD_140 v6.1.0 and have not heard or seen this problem in later softdevice. Can you attach your project so that i can try to replicate your problem on my desk?

  • Hello, I am attaching the light switch example, modified as per the recommendations of this example.8231.light_switch.zip

    I purposedly modified the project light_switch_server_nrf52840_xxAA_s140_7_0_1 in a clean SDK and Mesh SDK and tested this in a nRF52840 DK board to be sure everything was as vanilla as possible.

    If I use pin 0.31 for TX and 0.30 for RX I get the following signals in the oscilloscope:

    If I use pin 1.01 for TX and 1.03 for RX I get the following signals in the oscilloscope:

    The module I am using that has PA/LNA has the pins in port 1 and not on port 0. I would like to not have to design my board with two wires connecting pins from port 0 to port 1, but I could do it as a last measure.

    I also tried other pins on both port 0 and port 1 and the behaviour is the same. RX is never pulled up to 3V on port 1 pins after the periodic transmissions. This only works on pins of port 1.

  • Sorry for late response, i was on sick leave. I will take a look at it today, and if i can reproduce this with the softdevice you mentioned, then i need to contact the softdevice team to get more explanation on it.

  • Hi,

    I did not test this on the mesh, but tested this directly on the softdevice HRS example. 

    I tested this on port 0 (pint 30 and 31)

    The below is from P1.01 and P1.03 which also seems to work.

    So this is clearly not the problem with softdevice and it seems like they infact have fixed it.

    The problem must be in the Mesh code you are using. I noticed that you not checking the return value of  mesh_pa_lna_gpiote_enable function which is written to fail 

    The reason is that the check inside mesh_pa_lna_gpiote_enable is wrong

            (p_params->lna_cfg.gpio_pin >= ARRAY_SIZE(NRF_GPIO->PIN_CNF)) ||
            (p_params->pa_cfg.gpio_pin >= ARRAY_SIZE(NRF_GPIO->PIN_CNF)))
    The above is a bug since it only checks the gpio pin to be under port0 size and not on port1
    You should change the function to below
    uint32_t mesh_pa_lna_gpiote_enable(const mesh_pa_lna_gpiote_params_t * p_params)
    {
        if (p_params == NULL)
        {
            return NRF_ERROR_NULL;
        }
        if ((p_params->ppi_ch_id_set >= TIMER_PPI_CH_START &&
             p_params->ppi_ch_id_set <= TIMER_PPI_CH_STOP) ||
            (p_params->ppi_ch_id_clr >= TIMER_PPI_CH_START &&
             p_params->ppi_ch_id_clr <= TIMER_PPI_CH_STOP) ||
            (p_params->ppi_ch_id_set >= ARRAY_SIZE(NRF_PPI->CH)) ||
            (p_params->ppi_ch_id_clr >= ARRAY_SIZE(NRF_PPI->CH)) ||
            (p_params->ppi_ch_id_set == p_params->ppi_ch_id_clr) ||
            (p_params->gpiote_ch_id >= ARRAY_SIZE(NRF_GPIOTE->CONFIG)) ||
            (p_params->lna_cfg.gpio_pin >= 48) ||
            (p_params->pa_cfg.gpio_pin >= 48))
        {
            return NRF_ERROR_INVALID_PARAM;
        }
        m_gpiote.enabled = false;
        m_gpiote.params = *p_params;
        m_gpiote.enabled = true;
        pin_init(&p_params->lna_cfg);
        pin_init(&p_params->pa_cfg);
        return NRF_SUCCESS;
    }
Related