PIN_CNF Sense change state

RE: PIN_CNF Sense change state

Håkon Alseth — Mon, 15 Aug 2022 08:52:53 GMT

Hi,

If you are entering system off mode while the debug session is active, you're in "emulated system off", where it is strongly recommended that you add a loop after the systemoff call, as explained here:

https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.nrf52832.ps.v1.1/power.html?cp=4_2_0_17_1_0#unique_1150026639

Have you tried setting a pull-resistor before flipping the sense orientation?

Kind regards,

Håkon

RE: PIN_CNF Sense change state

Pero Krivic — Sat, 13 Aug 2022 16:32:36 GMT

Hello Hakon, after 2 months, I am back on this issue.

I am working in the debug mode, but I dont get any assert.. It is my understanding that debugger doesn't let me go into the SYSTEMOFF, so I cant really see what is actually going on in SYSTEMOFF, can I?

But, for the sake of investigation, I have commented out the line sd_power_system_off(); and observed the above described isue, that .SENSE gets inverted.

RE: PIN_CNF Sense change state

Håkon Alseth — Wed, 22 Jun 2022 11:56:38 GMT

Hi Mike,

Sounds like mcuboot is consuming your event.

Try to disable CONFIG_GPIO in mcuboot. This can be done by creating the folder my_project/child_image/

And in the child_image catalog, you create the file "mcuboot.conf" holding:

CONFIG_GPIO=n

Kind regards,

Håkon

RE: PIN_CNF Sense change state

Mike Austin (LPI) — Wed, 22 Jun 2022 04:36:19 GMT

Thanks Hakon. That explains the start up delay. I think I can work around that with my SYS_INIT approach.

Looks like my issue with the LATCH register is related to having the following in my proj.config

CONFIG_BOOTLOADER_MCUBOOT=y

With that enabled, I will get LATCH reset if I have a second GPIO trigger within the 400msec start up period, even if I disable all inputs within my SYS_INIT function. Without that in my proj.config, things seem to run as I would like them to - the first GPIO will trigger the device out of System OFF and any subsequent ones are just ignored.

I have the CONFIG_BOOTLOADER_MCUBOOT=y in my proj.config because in my end applicaiton, I want to implement OTA DFU, and it was indicated in the example code that was required.

Are you able to explain why that is impacting the LATCH register, but not the RESETREAS register, and whether there is a way to fix it and still be able to do OTA DFU?

Regards,

Mike

RE: PIN_CNF Sense change state

Håkon Alseth — Mon, 20 Jun 2022 12:26:47 GMT

Hi Mike,

You seem to be using NCS, based on the defines that you mention. When booting up, it requires the LFCLK source to run, which can take several 100 ms to start up.

This will occur before main() is entered, and you've mitigated this issue by configuring your GPIOs in PRE_KERNEL, which is the preferred solution.

Regarding LATCH issues, there are certain erratum's related to this that you should be aware of:

https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev3/ERR/nRF52832/Rev3/latest/anomaly_832_173.html#anomaly_832_173

https://infocenter.nordicsemi.com/topic/errata_nRF52832_Rev3/ERR/nRF52832/Rev3/latest/anomaly_832_210.html#anomaly_832_210

That being mentioned, if you have an on-going thread, please use this thread to continue discussing your specific scenario.

Kind regards,

Håkon

RE: PIN_CNF Sense change state

Håkon Alseth — Mon, 20 Jun 2022 12:19:01 GMT

Hi,

the nrfx_gpiote port event is setup to simulate edge triggering with a level triggered hardware signal.

It therefore uses the cpu to invert the .SENSE field to be able to provide an event when input signal occurs and when it goes back to idle state.

In the SYSTEMOFF scenario, we have to differentiate between a wake-up scenario and a interrupt scenario.

All pins with SENSE configured with either HIGH or LOW can generate a wake-up scenario from SYSTEMOFF, regardless of if the GPIOTE PORT event is enabled or not.

If you fear that you're getting interrupted while executing code in sleep_mode_enter, I would recommend that you wrap around the sensitive code and disable the GPIOTE IRQ before configuring and entering SystemOFF.

[quote user=""]My system either goes to sleep like everything's fine or it ends up in an infinite reset loop hell.[/quote]

This is more concerning. Is this due to an assert upon wakeup?

Have you tried to add the preprocessor symbol "DEBUG" to see where you assert?

Kind regards,

Håkon

RE: PIN_CNF Sense change state

Mike Austin (LPI) — Sun, 19 Jun 2022 23:14:44 GMT

I suspect we are encountering similar problems. Unfortunately I've not yet come up with the answer!

I'm also working on a project with the nRF52832 spending most of its time in System OFF. In mine, I have one of three different GPIO configured to trigger the device out of sleep mode. I then check the status of RESETREAS and LATCH, to determine what caused the exit from System Off (GPIO, NFC, harware reset etc) and in the case of a GPIO trigger, which GPIO caused it (via LATCH)

I'm having two issues, which I am not sure if they are related:

1. There is upwards of a 500msec delay between my GPIO triggering, and my main.c code starting up. Still working with the Nordic engineers on why this is, but I would be interested to see if you have something similar going on. I just measure this by toggling a GPIO as the first thing I do in my code, then measuring the time between the GPIO trigger and this GPIO toggle on my scope

2. If I get a second GPIO trigger in this 500msec period, it seems to reset my chip again, and I lose the contents of the LATCH register. The RESETREAS register remains valid, but LATCH ends up getting reset to 0, which means I can't determine which GPIO caused the exit from System OFF. I've even tried having a SYS_INIT call in PRE_KERNEL_2, where I make a change to the PIN_CNF[x] register for the appropriate GPIO, using

NRF_GPIO->PIN_CNF[x] &= 0x02;

so that I am disabling any influence these GPIO might have on the DETECT signal as early as possible. That code gets run within the first 200-400usec of the GPIO trigger, when my trigger signal is still in the active state. But its still not resolving my "sets LATCH to 0" problem.

Sorry I'm not helping solve your issue, but between what I am doing, and what you are doing, we might collectively get to the bottom of it!

Cheers,

Mike