Level based control of GPIOTE

RE: Level based control of GPIOTE

snoopy20 — Wed, 01 Nov 2023 16:12:48 GMT

Happy to report that the GPIO drive config is being observed and the pull-downs are also working in output mode, matching hmolesworth's reply. This means I have a solution!

RE: Level based control of GPIOTE

snoopy20 — Mon, 30 Oct 2023 08:43:42 GMT

Marvellous!

My revised PCB arrives today, so I'll build it and report back whether it works on the 810. I guess it will!

RE: Level based control of GPIOTE

hmolesworth — Mon, 30 Oct 2023 01:24:56 GMT

Pull-up and pull-down resistors can be enabled on an output pin on nRF52832 and nRF52840 (others not tested) and this is a really useful feature.

"A pull-resistor cannot be enabled on a output device" is not correct, although the Product Specification does show the pull-up and pull-down don't apply to an output pin. I have pointed out this issue in older posts, but the Product Specifications were not updated.

// Here are my measurement results, which prove the pullup/pull-down resistor is connected to the pin regardless
// of the input setting. nRF52832, 32MHz crystal, no 32kHz crystal, no Reset pin, SoftDevice loaded but not
// enabled, no peripherals enabled, idle. Power CR2032 coin cell, no ground other than PPK-2, no J-Link.
//
// This first table is default port settings after a reset, no changes:
//
// PPK-2  Meter  Conditions
// ====== ====== ==========
// 1.66uA 2.971V with errata workarounds, no i/o
// 1.51uA 2.985V   no errata workarounds, no i/o
//
// This Next table is port settings made after a reset, all 32 port pins identical, nothing connected to any of
// the 32 port pins, no errata applied:
//
// PPK-2  Meter   Direction    Input            Pullup         Drive Level      Sense Level    Output
// ====== ======  ==========   ==============   ============   ==============   ============== ===========
//
// 1.49uA 2.989V (PIN_OUTPUT | PIN_DISCONNECT | PIN_PULLNONE | PIN_DRIVE_S0S1 | PIN_SENSE_OFF) Driven Low
// 1.49uA 2.999V (PIN_OUTPUT | PIN_DISCONNECT | PIN_PULLDOWN | PIN_DRIVE_S0S1 | PIN_SENSE_OFF) Driven Low
// 6.47mA 2.894V (PIN_OUTPUT | PIN_DISCONNECT | PIN_PULLUP   | PIN_DRIVE_S0S1 | PIN_SENSE_OFF) Driven Low
// 6.47mA 2.889V (PIN_OUTPUT | PIN_CONNECT    | PIN_PULLUP   | PIN_DRIVE_S0S1 | PIN_SENSE_OFF) Driven Low
//
// 1.51uA 2.959V (PIN_OUTPUT | PIN_DISCONNECT | PIN_PULLNONE | PIN_DRIVE_S0S1 | PIN_SENSE_OFF) Driven High
// 6.42mA 2.877V (PIN_OUTPUT | PIN_DISCONNECT | PIN_PULLDOWN | PIN_DRIVE_S0S1 | PIN_SENSE_OFF) Driven High
// 1.53uA 2.938V (PIN_OUTPUT | PIN_DISCONNECT | PIN_PULLUP   | PIN_DRIVE_S0S1 | PIN_SENSE_OFF) Driven High
//
//
// This shows setting a port pin into active low output driven low is as good as leaving a pin floating
// when unused, with the added benefit that there is no possibility of port feedthrough if a floating pin
// drifts through the threshold.
//
// Looking at pull-up and pull down resistor values for the 32 pins:
//
//   (2.877Volts / 6.42mA) * 32 ==> 14.34K Ohm

Here is one of my older responses nrf52832-power-leakage which stian reported internally at the time

RE: Level based control of GPIOTE

snoopy20 — Sat, 28 Oct 2023 19:27:27 GMT

EVENTS_DOWN = task, 0, GPIO_PIN_CNF_DRIVE_S0S1
EVENTS_UP = task, 1, GPIO_PIN_CNF_DRIVE_S0S1
DEFAULT (OVERRIDE) = external weak pull-down, GPIO_PIN_CNF_DRIVE_S0D1

The diagram within the gpio section indicates drive_strength will be respected. I only need to add an external weak-pull down resistor.

RE: Level based control of GPIOTE

Håkon Alseth — Thu, 26 Oct 2023 12:55:09 GMT

Hi,

A pull-resistor cannot be enabled on a output device, so the GPIO_PIN_CNF_PULL line does not have any effect when the GPIO is configured with GPIO_PIN_CNF_DIR_Output.

When you disable, you have setup the specific GPIO to be a open-drain, commonly used in I2C pin operation.

The drive-level is set to standard-drive on '0' (output low), and disconnected on output high '1'.

This means that the GPIO will float when set to '1'.

You have 3 states:

* EVENTS_DOWN

* EVENTS_UP

* "default state"

How do you want your GPIO(s) to be set in each of these states?

Kind regards,

Håkon

RE: Level based control of GPIOTE

snoopy20 — Wed, 25 Oct 2023 20:58:25 GMT

Been looking into it this evening. I read that GPIO config is retained when GPIOTE takes over the pin output. I'm unsure but making an assumption that weak pull is still operational when pin is in outmode mode. A hopeful solution is:

NRF_GPIO->PIN_CNF[CFG_PIN_POWERMANAGER_FRONT_ENABLE] = pinDisconnectInputBuffer 
    | GPIO_PIN_CNF_DIR_Output << GPIO_PIN_CNF_DIR_Pos 
    | GPIO_PIN_CNF_DRIVE_S0D1 << GPIO_PIN_CNF_DRIVE_Pos 
    | GPIO_PIN_CNF_PULL_Pulldown << GPIO_PIN_CNF_PULL_Pos;
  
NRF_GPIOTE->CONFIG[CFG_GPIOTE_POWERMANAGER_FRONT] = GPIOTE_CONFIG_OUTINIT_High << GPIOTE_CONFIG_OUTINIT_Pos 
    | GPIOTE_CONFIG_MODE_Task << GPIOTE_CONFIG_MODE_Pos 
    | CFG_PIN_POWERMANAGER_FRONT_ENABLE << GPIOTE_CONFIG_PSEL_Pos;

NRF_PPI->CH[CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_GOOD].EEP = (uint32_t) &NRF_COMP->EVENTS_UP;
NRF_PPI->CH[CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_GOOD].TEP = (uint32_t) &NRF_GPIOTE->TASKS_SET[CFG_GPIOTE_POWERMANAGER_FRONT];
NRF_PPI->CH[CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_BAD].EEP = (uint32_t) &NRF_COMP->EVENTS_DOWN;
NRF_PPI->CH[CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_BAD].TEP = (uint32_t) &NRF_GPIOTE->TASKS_CLR[CFG_GPIOTE_POWERMANAGER_FRONT];

// UVLO
NRF_COMP->REFSEL = UVLO_REFERENCE << COMP_REFSEL_REFSEL_Pos;
NRF_COMP->TH = UVLO_HYSTERESIS_UP << COMP_TH_THUP_Pos | UVLO_HYSTERESIS_DOWN << COMP_TH_THDOWN_Pos;
NRF_COMP->PSEL = COMP_UVLO << COMP_PSEL_PSEL_Pos;
NRF_COMP->ENABLE = COMP_ENABLE_ENABLE_Enabled << COMP_ENABLE_ENABLE_Pos;
NRF_COMP->TASKS_SAMPLE = COMP_TASKS_SAMPLE_TASKS_SAMPLE_Trigger << COMP_TASKS_SAMPLE_TASKS_SAMPLE_Pos;

// wait a moment for voltage to stablize
// if it doesn't happen watchdog will reset
while (!NRF_COMP->RESULT) {
  NRF_COMP->TASKS_SAMPLE = 1;
};
NRF_COMP->EVENTS_DOWN = 0;

// must come after comparator to ensure output sync
NRF_PPI->CHENSET = 1 << CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_GOOD
  | 1 << CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_BAD
  | 1 << CFG_PPI_POWERMANAGER_UVLO_USB_BAD;

Then to enable the pin

NRF_GPIO->PIN_CNF[CFG_PIN_POWERMANAGER_FRONT_ENABLE] = pinDisconnectInputBuffer 
    | GPIO_PIN_CNF_DIR_Output << GPIO_PIN_CNF_DIR_Pos 
    | GPIO_PIN_CNF_DRIVE_S0S1 << GPIO_PIN_CNF_DRIVE_Pos;

And to disable it again

NRF_GPIO->PIN_CNF[CFG_PIN_POWERMANAGER_FRONT_ENABLE] = pinDisconnectInputBuffer 
    | GPIO_PIN_CNF_DIR_Output << GPIO_PIN_CNF_DIR_Pos 
    | GPIO_PIN_CNF_DRIVE_S0D1 << GPIO_PIN_CNF_DRIVE_Pos 
    | GPIO_PIN_CNF_PULL_Pulldown << GPIO_PIN_CNF_PULL_Pos;

RE: Level based control of GPIOTE

snoopy20 — Wed, 25 Oct 2023 15:55:10 GMT

[deleted]

RE: Level based control of GPIOTE

Håkon Alseth — Wed, 25 Oct 2023 08:29:00 GMT

Hi,

[quote user="snoopy20"]1. turn both off using GPIOTE_CONFIG_MODE_Disabled[/quote]

This will disable GPIOTE channel, and not really do anything with the state of the GPIO itself.

This is highly likely not the functionality you're after.

[quote user="snoopy20"]I may have a solution, if I leave GPIOTE Task enabled but instead switch GPIO to be an input with a pull-down enabled...?[/quote]

No, but you can use more PPI channels to ensure that other GPIOTE OUT channels are set in your wanted state at that time.

Can you share a diagram or similar on how you want your GPIOs to be set in each COMP state?

Kind regards,

Håkon

RE: Level based control of GPIOTE

snoopy20 — Mon, 23 Oct 2023 17:17:33 GMT

I think I have it. The UVLO is triggered by the two downstream circuits controlled by these enable pins, and the circuits are bucks which turn off fast and turn on slower. With that in mind when I want to turn either on...

1. turn both off using GPIOTE_CONFIG_MODE_Disabled
2. the comparator will now be in high.
3. Turn an output on using GPIOTE_CONFIG_MODE_Task and OUTINIT=high
4. Turn on the other output if it were already enabled.

Given the speed/delay of the buck(s) turning on the comparator event wont fire between steps 3 and 4 so all will be in sync.

RE: Level based control of GPIOTE

snoopy20 — Mon, 23 Oct 2023 16:52:10 GMT

I may have a solution, if I leave GPIOTE Task enabled but instead switch GPIO to be an input with a pull-down enabled...?

edit: datasheet suggests not. infocenter.nordicsemi.com/index.jsp

RE: Level based control of GPIOTE

snoopy20 — Mon, 23 Oct 2023 14:49:17 GMT

Hi,

Sorry that's an error (now corrected), the PPI event controls two pins, front and rear (I haven't tested this revised code yet, awaiting pcb arrival this week). The event actually controls three pins, but PPI only supports the single fork so I use two channels. Also one of the channels doesn't use the SET event.

No, I am now using NRF_COMP. I managed to make a pin available, but whether it's comparator or gpiote input the query remains the same. :)

All that matters is:

a) ensure the comparator is level high
b) set the gpiote pin high
c) do the above atomically - the comparator can't go low between a and b.

I occasionally need to override the GPIOTE output. At that point when I turn it back on it is not necessarily in sync with the comparator output. This is the problem with events rather than levels. Anyhow, it is a condition I must resolve.

Simplied init:

  // gpiote
  NRF_GPIOTE->CONFIG[CFG_GPIOTE_POWERMANAGER_FRONT] = GPIOTE_CONFIG_MODE_Disabled << GPIOTE_CONFIG_MODE_Pos | CFG_PIN_POWERMANAGER_FRONT_ENABLE << GPIOTE_CONFIG_PSEL_Pos;
  
  // ppi
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_GOOD].EEP = (uint32_t) &NRF_COMP->EVENTS_UP;
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_GOOD].TEP = (uint32_t) &NRF_GPIOTE->TASKS_SET[CFG_GPIOTE_POWERMANAGER_FRONT];
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_BAD].EEP = (uint32_t) &NRF_COMP->EVENTS_DOWN;
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_BAD].TEP = (uint32_t) &NRF_GPIOTE->TASKS_CLR[CFG_GPIOTE_POWERMANAGER_FRONT];
 
  NRF_PPI->CHENSET = 1 << CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_GOOD
    | 1 << CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_BAD;

  // UVLO
  NRF_COMP->REFSEL = UVLO_REFERENCE << COMP_REFSEL_REFSEL_Pos;
  NRF_COMP->TH = UVLO_HYSTERESIS_UP << COMP_TH_THUP_Pos | UVLO_HYSTERESIS_DOWN << COMP_TH_THDOWN_Pos;
  NRF_COMP->PSEL = COMP_UVLO << COMP_PSEL_PSEL_Pos;
  NRF_COMP->ENABLE = COMP_ENABLE_ENABLE_Enabled << COMP_ENABLE_ENABLE_Pos;

Imagine you want to override GPIOTE output, by toggling GPIOTE_CONFIG_MODE_[Disabled|Task], and when you choose task it must give the same output as the current comparator state.

Perhaps calling COMP.SAMPLE will fire and propagate the correct event?...
Andrew

RE: Level based control of GPIOTE

Håkon Alseth — Mon, 23 Oct 2023 14:40:09 GMT

Hi,

[quote user="snoopy20"]So, for some reason I thought GPIOTE PSEL had a null, it doesn't. That means I have to toggle from task to disable and vice versa sometimes, which potentially could race with the comparator output.

So when I come to set a GPIOTE output I have to:

a) ensure the comparator is level high
b) set the gpiote pin high
c) do the above atomically - the comparator can't go low between a and b.[/quote]

Your code disables the CFG_GPIOTE_POWERMANGER_FRONT /_REAR channels, ie. these will not be used by the GPIOTE module at all. Is this intended?

If you want 'n' amount of GPIOTE TASKs to occur when EVENTS_DOWN is triggered, you should configure all your GPIOTE channels as TASK.

In your PPI configuration, you seem to .FORK with the exact same TASK EP as originally set i CH[].TEP.

I highly suspect that you want the triggered GPIOTE OUT tasks to be reset in the .FORK operation? ie. if EVENTS_UP occurs, set "CFG_GPIOTE_POWERMANAGER_FRONT" and SET "CFG_GPIOTE_POWERMANAGER_REAR" ? Vice-versa on the EVENTS_DOWN ?

[quote user="snoopy20"]However related to the original question I must ensure the GPIOTE pin always has the correct output. My understanding is if the GPIOTE is enabled as a task after the comparator is running then the PPI wont be picked up, because it's not propagating continuously by clock. I may be wrong with this and it is a fundamental question.[/quote]

It is clear to me that you're using the NRF_COMP peripheral, and not a external circuit, as I initially thought. Sorry for misunderstanding.

GPIOTE is related to TASK and EVENT system. It can be tied towards an event or task occurring and performing a specific GPIO related task, like SET/CLR.

Please note that PPI cannot perform a logical operation, like evaluating a if/else condition. PPI is quite simple in terms of what features can be done without CPU intervention.

That being said, it looks like you want to set a given "bit pattern" on each event on a total of 3 GPIOs. Could you share the wanted state(s) based on each EVENTS_* that occurs?

Kind regards,

Håkon

RE: Level based control of GPIOTE

snoopy20 — Sat, 21 Oct 2023 16:28:17 GMT

So, for some reason I thought GPIOTE PSEL had a null, it doesn't. That means I have to toggle from task to disable and vice versa sometimes, which potentially could race with the comparator output.

So when I come to set a GPIOTE output I have to:

a) ensure the comparator is level high
b) set the gpiote pin high
c) do the above atomically - the comparator can't go low between a and b.

Some init code.

  // gpiote
  NRF_GPIOTE->CONFIG[CFG_GPIOTE_POWERMANAGER_USB] = GPIOTE_CONFIG_MODE_Task << GPIOTE_CONFIG_MODE_Pos | CFG_PIN_POWERMANAGER_USB_ENABLE << GPIOTE_CONFIG_PSEL_Pos;
  NRF_GPIOTE->CONFIG[CFG_GPIOTE_POWERMANAGER_FRONT] = GPIOTE_CONFIG_MODE_Disabled << GPIOTE_CONFIG_MODE_Pos | CFG_PIN_POWERMANAGER_FRONT_ENABLE << GPIOTE_CONFIG_PSEL_Pos;
  NRF_GPIOTE->CONFIG[CFG_GPIOTE_POWERMANAGER_REAR] = GPIOTE_CONFIG_MODE_Disabled << GPIOTE_CONFIG_MODE_Pos | CFG_PIN_POWERMANAGER_REAR_ENABLE << GPIOTE_CONFIG_PSEL_Pos;

  // ppi
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_UVLO_USB_BAD].EEP = (uint32_t) &NRF_COMP->EVENTS_DOWN;
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_UVLO_USB_BAD].TEP = (uint32_t) &NRF_GPIOTE->TASKS_CLR[CFG_GPIOTE_POWERMANAGER_USB];
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_GOOD].EEP = (uint32_t) &NRF_COMP->EVENTS_UP;
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_GOOD].TEP = (uint32_t) &NRF_GPIOTE->TASKS_SET[CFG_GPIOTE_POWERMANAGER_FRONT];
  NRF_PPI->FORK[CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_GOOD].TEP = (uint32_t) &NRF_GPIOTE->TASKS_SET[CFG_GPIOTE_POWERMANAGER_FRONT];
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_BAD].EEP = (uint32_t) &NRF_COMP->EVENTS_DOWN;
  NRF_PPI->CH[CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_BAD].TEP = (uint32_t) &NRF_GPIOTE->TASKS_CLR[CFG_GPIOTE_POWERMANAGER_REAR];
  NRF_PPI->FORK[CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_BAD].TEP = (uint32_t) &NRF_GPIOTE->TASKS_CLR[CFG_GPIOTE_POWERMANAGER_REAR];

  NRF_PPI->CHENSET = 1 << CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_GOOD
    | 1 << CFG_PPI_POWERMANAGER_UVLO_FRONTREAR_BAD
    | 1 << CFG_PPI_POWERMANAGER_UVLO_USB_BAD;

  // UVLO
  NRF_COMP->REFSEL = UVLO_REFERENCE << COMP_REFSEL_REFSEL_Pos;
  NRF_COMP->TH = UVLO_HYSTERESIS << COMP_TH_THUP_Pos;
  NRF_COMP->PSEL = COMP_UVLO << COMP_PSEL_PSEL_Pos;
  NRF_COMP->ENABLE = COMP_ENABLE_ENABLE_Enabled << COMP_ENABLE_ENABLE_Pos;
  NRF_COMP->TASKS_SAMPLE = COMP_TASKS_SAMPLE_TASKS_SAMPLE_Trigger << COMP_TASKS_SAMPLE_TASKS_SAMPLE_Pos;

  // wait a moment for voltage to stablize
  // if it doesn't happen watchdog will reset
  while (!NRF_COMP->RESULT) {
    NRF_COMP->TASKS_SAMPLE = 1;
  };
  NRF_COMP->EVENTS_DOWN = 0;

RE: Level based control of GPIOTE

snoopy20 — Sat, 21 Oct 2023 12:40:13 GMT

Hi Hakon,

I've resolved it a different way. The external comparator was due to all analog pins being used for ADC, but I've cleared one by means of some pin auxing and now have the built in comparator available.

So without the GPIOTE pin detect I now have comparator -> ppi -> GPIOTE pin out.

However related to the original question I must ensure the GPIOTE pin always has the correct output. My understanding is if the GPIOTE is enabled as a task after the comparator is running then the PPI wont be picked up, because it's not propagating continuously by clock. I may be wrong with this and it is a fundamental question.

Otherwise I intend to enable GPIOTE, enable the comparator, call comparator.sample (which I think will always fire one of the events? And then only disable the GPIOTE pin, but not the task, so it should be switching correctly.

I have to be careful as I need to disable the pin output then reconnect it transparent to the comparator output, which must always be outbound when I reenable the pin output.

Cheers!

Andrew

RE: Level based control of GPIOTE

Håkon Alseth — Fri, 20 Oct 2023 14:40:27 GMT

Hi,

With such a high input frequency, it will be problematic for the PPI/GPIOTE to be able to handle both events. This is because the propagated delay in PPI is based on the system as a whole, and one cannot guarantee that other PPI signals does not occur within the same timeframe. Also, do you require rising and falling edge detection of these two 5 MHz signals? If yes, then it would effectively double the frequency.

Kind regards,

Håkon

RE: Level based control of GPIOTE

snoopy20 — Thu, 19 Oct 2023 12:07:13 GMT

Hi,

LMV393 has a propagation of 0.2us, which is 5 MHz.

As you say it's synchronous to the 16MHz clock, so let's say at max there are 5 edges at 0.2us apart. Would PPI/GPIOTE be able to keep up driving an output pin using the SET/CLEAR events?

It sounds like it would, so long as the propagation didn't take more than 3 clock cycles.

RE: Level based control of GPIOTE

Håkon Alseth — Thu, 19 Oct 2023 11:53:54 GMT

Hi,

[quote user=""]What I can't determine from the datasheet is whether once the initial output of GPIOTE is set if PPI & GPIOTE are fully async to the clock in which case it would be like level control where they couldn't miss an event, or whether the clock is working to determine the event (like a D gate) in which case potentially the event could be missed.[/quote]

If I understand the scenario correct, you want two IN channels to, based on falling/rising edge-triggering, SET/CLR two other GPIOs. Please correct me if I'm mistaken.

GPIOTE IN/OUT, when connected through PPI, will be synchronous to the internal 16 MHz peripheral clock.

If more than one operation occurs on the same clock cycle, one event can be postponed to the next clock cycle.

There is however one scenario that can occur, which is errata #155:

https://infocenter.nordicsemi.com/topic/errata_nRF52810_Rev3/ERR/nRF52810/Rev3/latest/anomaly_810_155.html?cp=5_5_1_0_1_12

If you have two GPIOTE IN channels occurring within the timed scope (ie. < 1.3 us apart), you will hit this errata.

The side-effect of this errata workaround is higher current consumption, as the peripheral clock tree will be kept in sleep mode.

Kind regards,

Håkon