Using nrfjprog to read out the GPIO registers to check if any of the GPIOs are configured as output

RE: Using nrfjprog to read out the GPIO registers to check if any of the GPIOs are configured as output

Jørgen Holmefjord — Thu, 14 Dec 2023 15:21:52 GMT

[quote user="Learner"]So, you have no spotted anything wrong with the way I am configuring my pin P0.18 in io_charger_detect_initialise() and the overlay file.[/quote]

No, the config looks ok to me.

[quote user="Learner"]

Note, P0.18 can also be the RESET pin. So, I have this config in prj.conf and mcuboot.conf,

CONFIG_GPIO=y
CONFIG_GPIO_AS_PINRESET=n

[/quote]

This should be fine, as long as the PINRESET has not been previously enabled and the UICR was not erased between programming.

You can check this by reading out the NRF_UICR->PSELRESET[n] registers using the debugger:

>nrfjprog --memrd 0x10001200
0x10001200: FFFFFFFF                              |....|
>nrfjprog --memrd 0x10001204
0x10001204: FFFFFFFF                              |....|

[quote user="Learner"]

Learner said:
Digging a bit deeper I noticed (see line highlighted in yellow above) that only 3 out of 4 members of the the structure pm_state_info are defined. Note, this line was taken from a Nordic example.

Will this cause problems?

Any comment on the above question?

[/quote]

No, as far as I can see, only the state field of the struct is used in the pm_power_state_set() implementation on nRF52 series, which is called by pm_power_state_force().

RE: Using nrfjprog to read out the GPIO registers to check if any of the GPIOs are configured as output

Learner — Thu, 14 Dec 2023 09:28:58 GMT

Good Morning Jorgen,

Thank you.

I will try your suggestions. So, you have no spotted anything wrong with the way I am configuring my pin P0.18 in io_charger_detect_initialise() and the overlay file. Note, P0.18 can also be the RESET pin. So, I have this config in prj.conf and mcuboot.conf,

CONFIG_GPIO=y
CONFIG_GPIO_AS_PINRESET=n

[quote userid="92434" url="~/f/nordic-q-a/106555/using-nrfjprog-to-read-out-the-gpio-registers-to-check-if-any-of-the-gpios-are-configured-as-output/460207"]

Digging a bit deeper I noticed (see line highlighted in yellow above) that only 3 out of 4 members of the the structure pm_state_info are defined. Note, this line was taken from a Nordic example.

Will this cause problems?

[/quote]

Any comment on the above question?

Kind regards

Mohamed

RE: Using nrfjprog to read out the GPIO registers to check if any of the GPIOs are configured as output

Jørgen Holmefjord — Wed, 13 Dec 2023 21:14:27 GMT

Hi,

[quote user="Learner"]

But I am seeing the device is rebooting as soon as the function pm_power_state_force() is executed.

Any idea what else I could be dong wrong?

[/quote]

You can read out the reason for the wakeup in the start of main() by reading the NRF_POWER->RESETREAS register. If the wakeup is triggered by a GPIO (Field OFF set in the register), you should check that the state of the pin is correct compared to the sense level (that it is not pulled low externally), and that no other pins have SENSE enabled (you can read out the NRF_GPIO->PIN_CNF[n] registers right before entering SystemOFF in the debug session.

Best regards,
Jørgen

RE: Using nrfjprog to read out the GPIO registers to check if any of the GPIOs are configured as output

Learner — Wed, 13 Dec 2023 17:34:24 GMT

Hi Jorgen,

[quote userid="14926" url="~/f/nordic-q-a/106555/using-nrfjprog-to-read-out-the-gpio-registers-to-check-if-any-of-the-gpios-are-configured-as-output/460166"]Which revision of the nRF52833 chip are you using?[/quote]

QDAAB0

[quote userid="14926" url="~/f/nordic-q-a/106555/using-nrfjprog-to-read-out-the-gpio-registers-to-check-if-any-of-the-gpios-are-configured-as-output/460166"]Are you using an old version of nRF Connect SDK? Segger Embedded Studio support was deprecated in NCS v2.0.0.[/quote]

Yes, I am using an old version of nRF Connect SDK.

- Zephyr OS build v2.6.99-ncs1
- nRF Connect SDK v1.7.0
- nrfx 2.5.0
- MDK 8.40.2 -> it has support for QDAAB0
- SEGGER Embedded Studio for ARM
Release 5.60 Build 2021081102.47262
Nordic Edition
Windows x64

[quote userid="14926" url="~/f/nordic-q-a/106555/using-nrfjprog-to-read-out-the-gpio-registers-to-check-if-any-of-the-gpios-are-configured-as-output/460166"]If you are seeing 60uA from the nRF52833 itself, the chip is not in SystemOFF mode[/quote]

The 60 uA is from the whole system.

[quote userid="14926" url="~/f/nordic-q-a/106555/using-nrfjprog-to-read-out-the-gpio-registers-to-check-if-any-of-the-gpios-are-configured-as-output/460166"]Have you configured any pins as wakeup source from SystemOFF? Only GPIOs with SENSE enabled will work as wakeup source.[/quote]

No, I have not. I configured one of the pins as interrupt as shown in the attached code. This must be what I was doing wrong.

/**
 *****************************************************************************************************************************************************
 *  io_charger_detect_intpt()
 *
 *  @brief  Callback that handles the INT Interrupt upon detecting the DC supply has been reconnected during SHUTDOWN.
 *  @param  [in]  None
 *  @return [out] None
 *
 *****************************************************************************************************************************************************
 */
void io_charger_detect_intpt(const struct device *dev, struct gpio_callback *cb,uint32_t pins)
{
    if ( ( flash_static_data_copy_hb.shutdown_flag == POWER_SHUTDOWN_SOURCE_FORCED )      ||
         ( flash_static_data_copy_hb.shutdown_flag == POWER_SHUTDOWN_SOURCE_LOW_BATTERY )    )
    {
        /* Flag that causes the device to wake-up and exit the SHUTDOWN state */
        g_charger_detect = true;
//      io_led_on( GREEN_LED );
    }

    /* Log the new lid button state. */
    LOG_DBG("Charger Interrupt Detected at %" PRIu32 "\n", k_cycle_get_32());
}



/**
 *****************************************************************************************************************************************************
 *  io_charger_detect_initialise()
 *
 *  @brief  Callback that handles the INT Interrupt upon detecting the DC supply has been reconnected during SHUTDOWN.
 *  @param  [in]  None
 *  @return [out] None
 *
 *****************************************************************************************************************************************************
 */
void io_charger_detect_initialise(void)
{
    uint8_t                       ret;
    static struct gpio_callback   charger_cb_data;

    /* Setup the INT pin (P0.18) */
    io_charger_dev = device_get_binding( DT_GPIO_LABEL( DT_ALIAS( charger_int ), gpios ) );
    if ( io_charger_dev )
    {
        ret = gpio_pin_configure( io_charger_dev,
                                  DT_GPIO_PIN( DT_ALIAS( charger_int ), gpios ),
                                  GPIO_INPUT | DT_GPIO_FLAGS( charger_int, gpios ) | GPIO_PULL_UP );
        if ( ret == 0 )
        {
            // Read the initial status of the INT pin (P0.18).
            if ( !gpio_pin_get_raw( io_charger_dev, DT_GPIO_PIN(DT_ALIAS(charger_int), gpios) ) )
            {
                /* Log the state of the INT pin (P0.18). */
                LOG_WRN( "INT state is 0\n" );
            }
            else
            {
                /* Log the state of the INT pin (P0.18). */
                LOG_INF( "INT state is 1\n" );
            }

            g_charger_detect = false;

            /* Enable the charger INT interrupt */
            ret = gpio_pin_interrupt_configure( io_charger_dev,
                                                DT_GPIO_PIN(DT_ALIAS(charger_int), gpios),
                                                GPIO_INT_EDGE_TO_ACTIVE                     );
            if ( ret == 0 )
            {
                gpio_init_callback( &charger_cb_data, io_charger_detect_intpt, BIT( DT_GPIO_PIN( DT_ALIAS( charger_int ), gpios ) ) );
                if ( gpio_add_callback( io_charger_dev, &charger_cb_data ) < 0 )
                {
                    LOG_ERR( "charger_cb_data is NULL" );
                }
            }
            else
            {
                LOG_ERR( "Charger Detect interrupt not configured" );
            }
        }
        else
        {
            LOG_ERR( "Charger Detect pin not configured" );
        }
    }
    else
    {
        LOG_ERR( "Charger Detect not registered" );
    }
}

I am configuring my 'charger_int' pin in the attached overlay file as follows,

/ {
    leds {
        compatible = "gpio-leds";
        led0: led_0 {
            gpios = <&gpio0 5 GPIO_ACTIVE_LOW>;
            label = "Red Led";
        };
        led1: led_1 {
            gpios = <&gpio0 20 GPIO_ACTIVE_LOW>;
            label = "Green Led";
        };
    };

    pwmsnd {
        compatible = "pwm-leds";
        pwm_led00: pwm_led_0 {
            pwms = <&pwm0 4>;
            };
        pwm_led10: pwm_led_1 {
            pwms = <&pwm0 5>;
            };  
    };

    buttons {
        compatible = "gpio-keys";
        tamper: button_0 {
            gpios = <&gpio0 29 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
            label = "Tamper Button";
        };
        ambsns: button_1 {
                        gpios = <&gpio0 30 GPIO_ACTIVE_HIGH>;
            label = "Ambient Sensor";
                };
        charger_det: button_2 {
            gpios = <&gpio0 18 (GPIO_PULL_UP | GPIO_ACTIVE_LOW)>;
            label = "Charger INT";
        };
    };
    
     aliases {
        redled = &led0;
        blueled = &led1;
        snd-p = &pwm_led00;
        snd-n = &pwm_led10;
        tamper-button = &tamper;
        adcctl = &adc;
        ambient = &ambsns;
        charger-int = &charger_det;
    };
};

So, I modified my code and it now looks like this,

nrf_gpio_cfg_input( DT_GPIO_PIN( DT_ALIAS( charger_int ), gpios ), GPIO_PULL_UP );
NRF_GPIO_PIN_SENSE_LOW );
nrf_gpio_cfg_sense_input( DT_GPIO_PIN( DT_ALIAS( charger_int ), gpios ), GPIO_PULL_UP, NRF_GPIO_PIN_SENSE_LOW);

/* Before we disabled entry to deep sleep. Here we need to override
* that, then force a sleep so that the deep sleep takes effect.
*/
pm_power_state_force((struct pm_state_info){PM_STATE_SOFT_OFF, 0, 0});

LOG_INF("CPU IN SLEEP MODE"); /* As expected, this line is never executed */

But I am seeing the device is rebooting as soon as the function pm_power_state_force() is executed.

Any idea what else I could be dong wrong?

Digging a bit deeper I noticed (see line highlighted in yellow above) that only 3 out of 4 members of the the structure pm_state_info are defined. Note, this line was taken from a Nordic example.

Will this cause problems?

This is how the pm_state_info structure is defined in v1.7.0\zephyr\include\pm\state.h

struct pm_state_info {
enum pm_state state;

/**
* Some platforms have multiple states that map to
* one Zephyr power state. This property allows the platform
* distinguish them. e.g:
*
* power-states {
* state0: state0 {
* compatible = "zephyr,power-state";
* power-state-name = "suspend-to-idle";
* substate-id = <1>;
* min-residency-us = <10000>;
* exit-latency-us = <100>;
* };
* state1: state1 {
* compatible = "zephyr,power-state";
* power-state-name = "suspend-to-idle";
* substate-id = <2>;
* min-residency-us = <20000>;
* exit-latency-us = <200>;
* };
* }
*/
uint8_t substate_id;

/**
* Minimum residency duration in microseconds. It is the minimum
* time for a given idle state to be worthwhile energywise.
*
* @note 0 means that this property is not available for this state.
*/
uint32_t min_residency_us;

/**
* Worst case latency in microseconds required to exit the idle state.
*
* @note 0 means that this property is not available for this state.
*/
uint32_t exit_latency_us;
};

Kind regards

Mohamed

RE: Using nrfjprog to read out the GPIO registers to check if any of the GPIOs are configured as output

Jørgen Holmefjord — Wed, 13 Dec 2023 14:24:26 GMT

[quote user="Learner"]While running in debug mode I am sending the nrfjprog command and it works the first time around as shown above but not on subsequent tries. Why?[/quote]

Which revision of the nRF52833 chip are you using?

[quote user="Learner"]I am running a debug build and so, I am disabling the readback protection to allow debug in Segger Embedded Studio NE. [/quote]

Are you using an old version of nRF Connect SDK? Segger Embedded Studio support was deprecated in NCS v2.0.0.

[quote user="Learner"]I am sending the SoC into SYSTEM OFF mode using the code below. I believe this is working fine because I can see the current dropping to about 60 uA.[/quote]

If you are seeing 60uA from the nRF52833 itself, the chip is not in SystemOFF mode, but if this is from the entire system, it could be correct. SystemOFF current should be below 2uA. There is a system_off sample in Zephyr that can be used to test this. In the latest SDK version there is a new API to enter SystemOFF directly.

[quote user="Learner"]However, I do not seem to be able to wake the SoC up despite sending a 50 us interrupt pulse to one of the GPIO pins.[/quote]

Have you configured any pins as wakeup source from SystemOFF? Only GPIOs with SENSE enabled will work as wakeup source.

RE: Using nrfjprog to read out the GPIO registers to check if any of the GPIOs are configured as output

Learner — Wed, 13 Dec 2023 10:32:15 GMT

Good Morning Jorgen,

Thank you for your tips.

I am running a debug build and so, I am disabling the readback protection to allow debug in Segger Embedded Studio NE.

While running in debug mode I am sending the nrfjprog command and it works the first time around as shown above but not on subsequent tries. Why?

[quote userid="14926" url="~/f/nordic-q-a/106555/using-nrfjprog-to-read-out-the-gpio-registers-to-check-if-any-of-the-gpios-are-configured-as-output/459972"]I'm not sure which firmware you run on the board, but wakeup from System OFF will trigger a chip reset.[/quote]

I am sending the SoC into SYSTEM OFF mode using the code below. I believe this is working fine because I can see the current dropping to about 60 uA. However, I do not seem to be able to wake the SoC up despite sending a 50 us interrupt pulse to one of the GPIO pins.

Any suggestions?

pm_power_state_force((struct pm_state_info){PM_STATE_SOFT_OFF, 0, 0});

k_sleep( K_SECONDS(1) );

/* k_sleep should never exit, so the code below should never be executed
* if system off was correct. On the other hand if something has gone wrong
* then we will see it on terminal and LED.
*/
LOG_INF("CPU IN SLEEP MODE");

Kind regards

Mohamed

RE: Using nrfjprog to read out the GPIO registers to check if any of the GPIOs are configured as output

Jørgen Holmefjord — Tue, 12 Dec 2023 15:36:26 GMT

Hi,

Like the error message says, this means that the readback protection is enabled in your device. You can read more about this in the Access port protection chapter in the Product Specifications. Depending on the chip/DK revision, the protection might be enabled by default if it is not disabled by the firmware. Our latest SDK versions should disable this by default to allow debugging the applications, see more details in IN149 Informational Notice v1.1.

I'm not sure which firmware you run on the board, but wakeup from System OFF will trigger a chip reset. If the access port protection was not disabled by the firmware, and the chip is reset, you will likely see this behavior when you attach the debugger and the chip resets. The chip should still function when you see this error, it is just the debug interface that is disabled to protect the content of the chip from unauthorized access.

Best regards,
Jørgen