Why 'pwm_set_dt(xxx, 0)' can not set gpio floating on NCS SDK 3.0.2 ？

[Max_Singsun]

For power cost down, use dts config  to set pwm gpio H0D1 as follow:

pwm1_default: pwm1_default {
group1 {
psels = <NRF_PSEL(PWM_OUT1, 0, 26)>;
nordic,drive-mode = <NRF_DRIVE_H0D1>;
};
};

1. When on NCS 2.4.1,  pwm func 'pwm_set_dt(xxx, 0)' can set gpio floating

2. When on NCS 3.0.2, 'pwm_set_dt(xxx, 0)' can NOT set gpio floating, because current get up 50 uA !

How can I use  'pwm_set_dt(xxx, 0)' set pwm gpio floating ?  and get current cost down?

[Håkon Alseth]

Hi,

 

The code will, in ncs v3.0.2, set the GPIO as output high or low, if the duty cycle is either 100 % or 0 %.

If you are seeing 50 uA higher consumption than expected, it sounds like it is not the PWM itself that is causing this.

 

Kind regards,

Håkon

[Max_Singsun]

I find the key !

Now I use demo ''v3.0.2\zephyr\samples\basic\blinky_pwm" to test the problem.  I found that if add CONFIG_I2C=y to the demo, the current cost will increase about 50uA, and if I let CONFIG_I2C=n, then the current down to normal. Could u explain the phenomenon and tell me how to get it ?

[Håkon Alseth]

Hi,

 

I would recommend that you set your connected GPIOs in a idle state, as it sounds like there are signals that are floating on your board.

Is this a custom board? Please check connections to external sensors, and ensure that the connected sensors are idle, by for instance having pull-up on the SDA/SCL lines.

 

Kind regards,

Håkon

[Max_Singsun]

First, I test on DK board finally, except for the LED which uses P0.19, no other GPIO is used, no external sensors

[Max_Singsun]

test code as above pic

[Håkon Alseth]

Hi,

 

Q1: What is connected on your external board? Your current firmware does not set anything in a idle state, in terms of SDA/SCL.

Q2: Do you have external pull resistors?

Q3: Have you disabled serial via CONFIG_SERIAL=n?

 

Kind regards,

Håkon

[Max_Singsun]

Let me rephrase the que，our product requires PWM to drive the LED((P0.26 drive LED) and I2C to drive the Motion Sensor. However, on our product board(NCS 3.0.2), when we use pwm and I2C together, in idle state(use "pwm_set_dt(x,0)" to stop pwm), bottom current  is too high, about 50~60+uA. Our previous product was based on NCS 2.4.1,  I2C and PWM are used in the same way，but we did not find such an issue, bottom current  is less than 10uA.

For trying to address issue, We did such tests:

1. On product board(P0.26 drive LED), disconnect I2C pin(P0.03/P0.04) and sensor,  high bottom current exist. It means the current issue is not related to external circuits

2. On product board(P0.26 drive LED), keep I2C pin disconnect, let CONFIG_I2C=n and delete all I2C application code(delete I2C init and other I2C ops), high bottom current disappear(bottom current  is about 5~6 uA).

3. On DK board（as comparative experiment, P0.19 drive LED）, use blinky_pwm to confirm, when add CONFIG_I2C=y, the issue can be reproduced.

It seems just add CONFIG_I2C=y to project with pwm  function,  high bottom current issue will occurs.

[Håkon Alseth]

Hi,

 

Setting CONFIG_I2C=y will cause an added current consumption due to the pins floating.

Try adding a internal pull-up resistor and see if this helps with the current consumption.

 

When running on nRF52-DK, with CONFIG_SERIAL=n, I see this current consumption.

* CONFIG_I2C=n : ~0.3 mA

* CONFIG_I2C=y : ~0.35 mA

* CONFIG_I2C=y + SDA/SCL pin pull up: ~0.3 mA

PS: PWM is active here.

Please note that if I set pwm = 0 % or 100 %, I see < 10 uA.

 

Here's the nrf52dk_nrf52832.overlay file with pull-up on SDA/SCL P0.26/P0.27:

&pinctrl {
	i2c0_default: i2c0_default {
		group1 {
			psels = <NRF_PSEL(TWIM_SDA, 0, 26)>,
				<NRF_PSEL(TWIM_SCL, 0, 27)>;
			bias-pull-up;
		};
	};
};

 

Please note that the I2C is now idle, and if started; you should use the pm_device API to set it to sleep/active state, similar to what is shown here:

https://github.com/nrfconnect/sdk-zephyr/blob/ncs-v3.1.1/samples/sensor/apds9960/src/main.c#L80-L83

   

Kind regards,

Håkon

[Max_Singsun]

Hi Hakon, 

I try your code on my DK board, I found i2c0 is okay, but if I change i2c0 to i2c1,  and use P0.03/P0.04, the issue（bottom current increase） can be reproduce, as below: 

&pinctrl {
    i2c1_default: i2c1_default {  //use i2c1, and P0.03/P0.04
        group1 {
        psels = <NRF_PSEL(TWIM_SDA, 0, 4)>,
        <NRF_PSEL(TWIM_SCL, 0, 3)>;
        bias-pull-up;
        };
    };
};

[Håkon Alseth]

Hi,

 

If the I2C is active, it will raise your current consumption, and you will need to do as I previously shared, ie. turn off the hardware peripheral:

Håkon Alseth said:

Please note that the I2C is now idle, and if started; you should use the pm_device API to set it to sleep/active state, similar to what is shown here:

https://github.com/nrfconnect/sdk-zephyr/blob/ncs-v3.1.1/samples/sensor/apds9960/src/main.c#L80-L83

 And pull-up resistors shall be applied when the I2C is disabled.

 

Can you please try to disable I2C and apply pull-ups to the pins when entering sleep in this scenario?

Max_Singsun said:

2. On product board(P0.26 drive LED), keep I2C pin disconnect, let CONFIG_I2C=n and delete all I2C application code(delete I2C init and other I2C ops), high bottom current disappear(bottom current  is about 5~6 uA).

Kind regards,

Håkon

[Max_Singsun]

Hi Hakon,

I 've got the point:  if replace "i2c1" to "i2c0  in overlay file, then the issue dispeared.  I mean that using i2c1 and P0.03/P0.04 may have some bugs in ncs 3.0.2, if you are not sure, you can try i2c1 and P0.03/P0.04 to confirm if it can work, as:

&pinctrl {
    i2c1_default: i2c1_default {  //use i2c1, and P0.03/P0.04
        group1 {
        psels = <NRF_PSEL(TWIM_SDA, 0, 4)>,
        <NRF_PSEL(TWIM_SCL, 0, 3)>;
        bias-pull-up;
        };
    };
};

I want to know why i2c1 and P0.03/P0.04 cannot work together.

[Håkon Alseth]

Hi,

 

spi1 is enabled by default in the nrf52dk board files:

https://github.com/nrfconnect/sdk-zephyr/blob/main/boards/nordic/nrf52dk/nrf52dk_nrf52832.dts#L189-L190

Could you please try what I previously described?

  

Kind regards,

Håkon