GPIO Latch not behaving consistently

RE: GPIO Latch not behaving consistently

Susheel Nuguru — Wed, 20 Jul 2022 08:26:27 GMT

unfortunately the driver owns all gpio ports once enabled. You can try to change that behavior by replace GPIO_COUNT with 1 in nrfx_gpiote.c and then this driver will not sniff port 1 gpio pins.

#if defined(NRF_GPIO_LATCH_PRESENT)
static bool latch_pending_read_and_check(uint32_t * latch)
{
    nrf_gpio_latches_read_and_clear(0, GPIO_COUNT, latch);

    for (uint32_t port_idx = 0; port_idx < GPIO_COUNT; port_idx++)
    {
        if (latch[port_idx])
        {
            /* If any of the latch bits is still set, it means another edge has been captured
             * before or during the interrupt processing. Therefore event-processing loop
             * should be executed again. */
            return true;
        }
    }
    return false;
}

RE: GPIO Latch not behaving consistently

maxg — Wed, 20 Jul 2022 06:09:50 GMT

In this particular application, I'd like to read the latch directly than to rely on any interrupts/handlers/callbacks from GPIOTE. If I want to do that, should I be OK if I sit it on its own separate port, e.g. my sensor on P0 and everything I want to read via latch on P1?

RE: GPIO Latch not behaving consistently

Susheel Nuguru — Wed, 20 Jul 2022 05:39:45 GMT

Ok, glad that you wrote that you are using some other sensors on that port. In that case you must have enabled nrfx_gpiote driver which then owns the gpio ports (with config NRF_GPIO_LATCH_PRESENT)

.You should not try to figure out if the pin sense has been detected in the application logic but instead rely that the handler set in nrfx_gpiote_input_configure will be called when the gpiote driver has processed the detected sense on your pin.

If you want to handle the pin directly in your application then you need to disable NRFX_GPIOTE which then relinquishes control on the port.

RE: GPIO Latch not behaving consistently

maxg — Tue, 19 Jul 2022 18:22:07 GMT

I'm sorry Susheel. I started moving code to a minimally reproducible example, and it looks like some other sensor reads are affecting how this latch reading code behaves.

while (1) {
	// NRF_POWER->SYSTEMOFF = 1;
	// LOG_INF("Polling sensor...");
	struct sensor_value pos_x, pos_y;
	sensor_sample_fetch(dev);
	sensor_channel_get(dev, SENSOR_CHAN_POS_DX, &pos_x);
	sensor_channel_get(dev, SENSOR_CHAN_POS_DY, &pos_y);

	if (old_pos_x.val1 != pos_x.val1 || old_pos_y.val1 != pos_y.val1) {
		LOG_INF("x: %d, y: %d", pos_x.val1, pos_y.val1);
	}

	// nrf_gpio_latches_read(0, 2, p_masks);


	NRF_P1->LATCH = NRF_P1->LATCH;
	(void)NRF_TIMER1->EVENTS_COMPARE[0];
	pmask = NRF_P1->LATCH;

	// uint32_t pmask = p_masks[1];

	// if ((pmask & (1U << 13U)) || (pmask & (1U << 12U))){
	if (pmask != 0){
		LOG_INF("Event: %d", pmask);
		pmask_old = pmask;
	}


	old_pos_x = pos_x;
	old_pos_y = pos_y;

	//k_sleep(K_MSEC(10));
}

I'm using the PMW3360 driver (https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/drivers/pmw3360.html) and am not immediately sure why this causes the latch to not behave as expected. I haven't had a chance to go through the code for the driver yet.

Here's my full device tree:

&pinctrl {
    spi1_default_alt: spi1_default_alt {
        group1 {
            psels = <NRF_PSEL(SPIM_SCK, 0, 2)>,
                    <NRF_PSEL(SPIM_MISO, 0, 26)>,
                    <NRF_PSEL(SPIM_MOSI, 0, 27)>;
        };
    };

    spi1_sleep_alt: spi1_sleep_alt {
        group1 {
            psels = <NRF_PSEL(SPIM_SCK, 0, 2)>,
                    <NRF_PSEL(SPIM_MISO, 0, 26)>,
                    <NRF_PSEL(SPIM_MOSI, 0, 27)>;
            // low-power-enable;
        };
    };
};

&spi1 {
    compatible = "nordic,nrf-spim";
    status = "okay";
    pinctrl-0 = <&spi1_default_alt>;
    pinctrl-1 = <&spi1_sleep_alt>;
    pinctrl-names = "default", "sleep";
    cs-gpios = <&gpio1 14 0>;

    pmw3360@0 {
            compatible = "pixart,pmw3360";
            reg = <0>;
            irq-gpios = <&gpio1 15 0>;
            spi-max-frequency = <2000000>;
            label = "PMW3360";
    };
};

/ {
    mbuttons { 
        compatible = "any,spdt-switch";
        rmb: switch_0 { 
            ncgpios = <&gpio1 12 0>;
            nogpios = <&gpio1 13 0>;
        };
    };
};

Is it likely to be the case that, since I'm using GPIOs on port 1 for IRQ (sensor motion) & CS for the sensor, the driver is (spuriously?) handling the latch behavior for the entire port?

If I want to use the latch functionality in the way that I'm attempting to now, should I keep those pins I want to operate on a latch with on a totally separate port, e.g. motion sensor and other peripherals on port 0, GPIO inputs with latch on port 1? Or should there be a way I can do this on the same port while not messing with the functionality?

RE: GPIO Latch not behaving consistently

maxg — Tue, 19 Jul 2022 18:05:44 GMT

When I add this, it seems to run through my main every single time I actuate the switch, without fail.

RE: GPIO Latch not behaving consistently

Susheel Nuguru — Tue, 19 Jul 2022 11:54:54 GMT

That is strange,

Can you add

NRF_POWER->SYSTEMOFF = 1.

before nrf_gpio_latches_read_and_clear. Just to check if the chip power state affects the detection of the sense pins? Something like below.

while(1) {

NRF_POWER->SYSTEMOFF = 1.
// I've also tried this one, with p_masks etc
// pmask = nrf_gpio_latches_read_and_clear(0, 2, p_masks);

RE: GPIO Latch not behaving consistently

maxg — Mon, 18 Jul 2022 19:38:52 GMT

This log statement

LOG_INF("Pin 12: %d", NRF_P1->PIN_CNF[12]);
LOG_INF("Pin 13: %d", NRF_P1->PIN_CNF[13]);

Yields:

I: Pin 12: 131084
I: Pin 13: 196620

131084 = 0b100000000000001100

196620 = 0b110000000000001100

Per https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fgpio.html,

Pin 13 seems to be configured correctly for sense and pin 12 isn't (!). I'm not sure why. Forcing the config via

NRF_P1->PIN_CNF[12] |= NRF_GPIO_PIN_SENSE_LOW << GPIO_PIN_CNF_SENSE_Pos;
NRF_P1->PIN_CNF[13] |= NRF_GPIO_PIN_SENSE_LOW << GPIO_PIN_CNF_SENSE_Pos;

Makes the P1.12 value match P1.13's PIN_CNF, but doesn't seem to yield a different behavior.

I think that connect and all the other parameters for input seem to be set correctly. It's very possible I'm missing something here.

RE: GPIO Latch not behaving consistently

Susheel Nuguru — Mon, 18 Jul 2022 19:12:00 GMT

There is nothing obviously wrong that points out to me.

Can you check if nrf_gpio_cfg_sense_input has actually configured the GPIO config register to enable the sense configuration on those pins? The reason I am asking to check is to see if the NRF_DT_GPIOS_TO_PSEL is being decoded correctly from your device tree config.