GPIO, interrupt & timer latencies larger than expected.

RE: GPIO, interrupt & timer latencies larger than expected.

Håkon Alseth — Mon, 18 Oct 2021 07:04:23 GMT

Hi,

[quote user="somename"]I experience exactly the same issue on a different MCU devboard from different vendor running different (but doing the same thing) test program, so most likely this should be EMI issue...[/quote]

Did you try using a pull-resistor to see if this helps the scenario?

Kind regards,

Håkon

RE: GPIO, interrupt & timer latencies larger than expected.

somename — Mon, 18 Oct 2021 01:46:26 GMT

I experience exactly the same issue on a different MCU devboard from different vendor running different (but doing the same thing) test program, so most likely this should be EMI issue...

RE: GPIO, interrupt & timer latencies larger than expected.

somename — Sat, 16 Oct 2021 11:49:43 GMT

[quote userid="2115" url="~/f/nordic-q-a/80481/gpio-interrupt-timer-latencies-larger-than-expected/334282#334282"]This handler looks to be empty, so no need to define it. It will cause the CPU to be interrupted on every input pulse:[/quote]

changed gpio handler argument to NULL, no visible changes, still the same

RE: GPIO, interrupt & timer latencies larger than expected.

Håkon Alseth — Fri, 15 Oct 2021 08:49:50 GMT

Hi,

Thank you for confirming.

This handler looks to be empty, so no need to define it. It will cause the CPU to be interrupted on every input pulse:

nrfx_gpiote_in_init(INPUT_CLOCK_PIN, &clock_pin_conf, /*empty_gpiote_handler*/ NULL);

Unless you have an external pull-resistor on the pin, could you try to enable the pull-down resistor in the pin itself?

  nrf_gpio_cfg(INPUT_CLOCK_PIN,
               NRF_GPIO_PIN_DIR_INPUT,
               NRF_GPIO_PIN_INPUT_CONNECT,
               /*NRF_GPIO_PIN_NOPULL*/ NRF_GPIO_PIN_PULLDOWN,
               NRF_GPIO_PIN_S0S1,
               NRF_GPIO_PIN_NOSENSE);

not that important but: In function timer_handler, you can use the nrf_gpio_pin_toggle(OUTPUT_TEST_SIGNAL_PIN); instead.

Kind regards,

Håkon

RE: GPIO, interrupt & timer latencies larger than expected.

somename — Thu, 14 Oct 2021 16:53:55 GMT

Yes, it equals 0x40006100

RE: GPIO, interrupt & timer latencies larger than expected.

Håkon Alseth — Thu, 14 Oct 2021 13:15:08 GMT

Hi,

[quote user="somename"]

Yes, I did, line 65 of the code example I provided:

65: *(volatile uint32_t *)(NRF_GPIOTE_BASE + 0x600 + (4 * 0)) = 1;//errata [155] GPIOTE: IN event may occur more than once on input edge

however, not sure if it is a right place.

[/quote]

It should be in the correct place, given that the GPIOTE IN channel 0 is being used.

Could you check what the IN address is?

uint32_t event_addr = nrfx_gpiote_in_event_addr_get(INPUT_CLOCK_PIN);

This should return 0x40006100 if EVENTS_IN[0] is used:

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/gpiote.html?cp=4_2_0_20_3#topic

Kind regards,

Håkon

RE: GPIO, interrupt & timer latencies larger than expected.

somename — Wed, 13 Oct 2021 15:50:06 GMT

[quote userid="2115" url="~/f/nordic-q-a/80481/gpio-interrupt-timer-latencies-larger-than-expected/333961#333961"]Did you apply the workaround described in this errata?[/quote]

Yes, I did, line 65 of the code example I provided:

65: *(volatile uint32_t *)(NRF_GPIOTE_BASE + 0x600 + (4 * 0)) = 1;//errata [155] GPIOTE: IN event may occur more than once on input edge

however, not sure if it is a right place.

I assume GPIOTE channel 0 is used, as no other GPIO pins are used in this code, and library code starts allocating from channel 0.

RE: GPIO, interrupt & timer latencies larger than expected.

Håkon Alseth — Wed, 13 Oct 2021 13:25:20 GMT

Hi,

[quote user="somename"]

1. Do you mean to have an empty event handler and pass false to disable interrupts in

nrfx_gpiote_in_event_enable(INPUT_CLOCK_PIN, false);

? Or there other ways to omit the handler too?

[/quote]

Sorry, I misunderstood your wanted behavior. If you want to get an event after ~96 us, then it should be OK, but please note that you're now using the CPU to detect this scenario, and if you have other tasks running, like the bluetooth link, you can get interrupted.

[quote user="somename"]

Issue that I see here that output pulse period is not fixed and variates.

If there is an input 4MHz clock, and timer compare value is set to 372,

I expect output pulse width (time between two compare events) to be

1/4000000*372 = 93 us, but shortest pulses visible on a picture are about 45us each,

i.e compare event happens 2x more times than expected?

[/quote]

Did you apply the workaround described in this errata?

https://infocenter.nordicsemi.com/index.jsp?topic=%2Ferrata_nRF52832_Rev2%2FERR%2FnRF52832%2FRev2%2Flatest%2Fanomaly_832_155.html&cp=4_2_1_1_1_41

Kind regards,

Håkon

RE: GPIO, interrupt & timer latencies larger than expected.

somename — Tue, 12 Oct 2021 18:36:27 GMT

[quote userid="2115" url="~/f/nordic-q-a/80481/gpio-interrupt-timer-latencies-larger-than-expected/333712#333712"]* Lower the input frequency (let's say 2 MHz) to see how it behaves then?[/quote]

I used test signal from oscilloscope, it has 2KHz pulses,

and at this frequency output pulse width is usually

correct (i.e. if I count input pulses, they match timer compare value),

but sometimes there are still shorter intervals between timer compare events

RE: GPIO, interrupt & timer latencies larger than expected.

somename — Tue, 12 Oct 2021 17:27:46 GMT

1. Do you mean to have an empty event handler and pass false to disable interrupts in

nrfx_gpiote_in_event_enable(INPUT_CLOCK_PIN, false);

? Or there other ways to omit the handler too?

2. Ok, tried this.

3. I can't control input frequency for this task, it is decied by other device. In this specific case it is 4MHz according to oscilloscope measurements.

Here is the complete minimal compilable example that demonstrates the problem.
There is an input 4MHz clock on clock pin 3, and output test signal is generated on pin 19. Both are recorded by oscilloscope. Output pin is toggled in timer compare event.

Is everything in this code ok?

#include "nrfx_ppi.h"
#include "nrfx_timer.h"
#include "nrfx_gpiote.h"
#include "nrf_delay.h"
#include "nrf_gpio.h"
#include "nrf_clock.h"
#include "nrfx_clock.h"


#define INPUT_CLOCK_PIN 3
#define OUTPUT_TEST_SIGNAL_PIN 19
#define TIMER_COMPARE_VALUE 372

static nrf_ppi_channel_t ppi_channel1;
const nrfx_timer_t clock_counter = NRFX_TIMER_INSTANCE(1);

static void  empty_gpiote_handler(nrfx_gpiote_pin_t pin, nrf_gpiote_polarity_t action)
{
}

void empty_clock_event_handler(nrfx_clock_evt_type_t event)
{
}

static void timer_handler(nrf_timer_event_t event_type, void * p_context)
{
  if (event_type != NRF_TIMER_EVENT_COMPARE0)
    return;
  // toggle output pin on each timer compare event
  if (nrf_gpio_pin_out_read(OUTPUT_TEST_SIGNAL_PIN))
    NRF_P0->OUTCLR = 1 << OUTPUT_TEST_SIGNAL_PIN;
  else
    NRF_P0->OUTSET = 1 << OUTPUT_TEST_SIGNAL_PIN;
}

int main(void)
{
  NRF_POWER->TASKS_CONSTLAT = 1;

  nrfx_clock_init(empty_clock_event_handler);
  nrfx_clock_hfclk_start();
  while(!nrfx_clock_hfclk_is_running());

  nrf_gpio_cfg(INPUT_CLOCK_PIN,
               NRF_GPIO_PIN_DIR_INPUT,
               NRF_GPIO_PIN_INPUT_CONNECT,
               NRF_GPIO_PIN_NOPULL,
               NRF_GPIO_PIN_S0S1,
               NRF_GPIO_PIN_NOSENSE);

  nrf_gpio_cfg(OUTPUT_TEST_SIGNAL_PIN,
               NRF_GPIO_PIN_DIR_OUTPUT,
               NRF_GPIO_PIN_INPUT_DISCONNECT,
               NRF_GPIO_PIN_NOPULL,
               NRF_GPIO_PIN_H0H1,
               NRF_GPIO_PIN_NOSENSE);

  nrfx_gpiote_init();

  nrfx_ppi_channel_alloc(&ppi_channel1);

  nrfx_gpiote_in_config_t clock_pin_conf = NRFX_GPIOTE_CONFIG_IN_SENSE_LOTOHI(true);
  nrfx_gpiote_in_init(INPUT_CLOCK_PIN, &clock_pin_conf, empty_gpiote_handler);

  *(volatile uint32_t *)(NRF_GPIOTE_BASE + 0x600 + (4 * 0)) = 1;//errata [155] GPIOTE: IN event may occur more than once on input edge

  nrfx_ppi_channel_assign(ppi_channel1,
                             nrfx_gpiote_in_event_addr_get(INPUT_CLOCK_PIN),
                             nrfx_timer_task_address_get(&clock_counter,
                                                            NRF_TIMER_TASK_COUNT));
  nrfx_ppi_channel_enable(ppi_channel1);

  nrfx_gpiote_in_event_enable(INPUT_CLOCK_PIN, false);

  nrfx_timer_config_t timer_cfg = NRFX_TIMER_DEFAULT_CONFIG;
  timer_cfg.mode = NRF_TIMER_MODE_COUNTER;
  timer_cfg.bit_width = NRF_TIMER_BIT_WIDTH_16;
  nrfx_timer_init(&clock_counter, &timer_cfg, timer_handler);

  nrfx_timer_clear(&clock_counter);
  nrfx_timer_compare(&clock_counter, NRF_TIMER_CC_CHANNEL0, TIMER_COMPARE_VALUE, true);

  nrf_timer_shorts_enable(clock_counter.p_reg, NRF_TIMER_SHORT_COMPARE0_CLEAR_MASK);
  nrf_timer_event_clear(clock_counter.p_reg, NRF_TIMER_EVENT_COMPARE0);
  nrfx_timer_enable(&clock_counter);

  while(1)
  {
  }

  return 0;
}

Issue that I see here that output pulse period is not fixed and variates.

If there is an input 4MHz clock, and timer compare value is set to 372,

I expect output pulse width (time between two compare events) to be

1/4000000*372 = 93 us, but shortest pulses visible on a picture are about 45us each,

i.e compare event happens 2x more times than expected?

RE: GPIO, interrupt & timer latencies larger than expected.

Håkon Alseth — Tue, 12 Oct 2021 11:10:22 GMT

Hi,

[quote user="somename"]basically I think about connecting clock line to SPIS CLK, leave MOSI, MISO unconnected, make some loop connection from one GPIO to chip select pin in order to emulate started transaction. And then count number of bytes received. Something like this.[/quote]

If you always receive byte-aligned amount of pulses, that will work.

In your current design, could you try to:

* Omit the GPIOTE event handler

* Use TIMER SHORTS to clear the timer on COMPARE0 instead of a PPI channel

* Lower the input frequency (let's say 2 MHz) to see how it behaves then?

Kind regards,

Håkon

RE: GPIO, interrupt & timer latencies larger than expected.

somename — Mon, 11 Oct 2021 19:25:35 GMT

basically I think about connecting clock line to SPIS CLK, leave MOSI, MISO unconnected, make some loop connection from one GPIO to chip select pin in order to emulate started transaction. And then count number of bytes received. Something like this.

RE: GPIO, interrupt & timer latencies larger than expected.

somename — Mon, 11 Oct 2021 19:21:24 GMT

What about possibility of using SPIS peripherial for counting incoming clock pulses?

RE: GPIO, interrupt & timer latencies larger than expected.

somename — Mon, 11 Oct 2021 18:38:30 GMT

Tried to apply,

there is some effect,

but timer compare events are still triggered at variable time periods

RE: GPIO, interrupt & timer latencies larger than expected.

Håkon Alseth — Mon, 11 Oct 2021 13:01:17 GMT

Hi,

Have you looked at errata #155 ?

https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev2/ERR/nRF52832/Rev2/latest/anomaly_832_155.html?cp=4_2_1_1_1_41

This is crucial that you apply.

Kind regards,

Håkon

RE: GPIO, interrupt & timer latencies larger than expected.

somename — Sat, 09 Oct 2021 16:19:55 GMT

Ok, second part of my post maybe stupid,
gpio library functions have some overhead, and by writing directly to the GPIO ports I get up to 8MHz switching speed.
But it is not relevant.

Why the timer setup is not working as expected, and what is the max frequency of external signal that can be reliably detected by GPIOTE events mechanism? What is the latency of timer COUNT task and COMPARE event?