SPI CS pin input vs output inactive power consumption

[Miguel Ferreira]

Hi,

I was checking the HAL for SPI in master mode and notice that when pm_device_action_run(<spi_device>, PM_DEVICE_ACTION_SUSPEND); the CS pin isnt changed since it status change after every transmission to output inactive : https://github.com/nrfconnect/sdk-zephyr/blob/v3.5.99-ncs1/drivers/pinctrl/pinctrl_nrf.c#L136

On the other hand, in the spim driver the SS pin is set as input when the pm action is to suspend: https://github.com/nrfconnect/sdk-hal_nordic/blob/8f013ea950f41bf69b18bf688bfb0dd80a3fdc44/nrfx/drivers/src/nrfx_spim.c#L465 . However, the code never reaches this point because the pinctrl is taking care of setting the pins to suspend state.

My question is what is the difference between both, how setting the pin as input differ as setting the pin as ouput inactive.

Thank you!

[Vidar Berg]

Hi,

The SS pin is controlled as a regular GPIO by the driver, not by the SPIM peripheral itself like MISO, MOSI, and CLK. Therefore, it is not the responsibility of the pinctrl module to configure this pin. The driver should probably have reconfigured this pin to its reset state to match the behavior when pinctrl is not enabled.

My question is what is the difference between both, how setting the pin as input differ as setting the pin as ouput inactive.

Output inactive corresponds to an active low output, i.e., the SS signal will be driven low.  

But why do you need to suspend the SPIM peripheral? Are you experiencing high sleep currents between SPIM transactions?

Best regards,

Vidar

Edit: The chip select signal is almost always active low, which means the pin will be driven high when set to inactive. Whether this will lead to any additional current consumption or not depends on the SS input on your SPI slave sensor. 

[Miguel Ferreira]

Hi,
Thanks for the reply. I understand that the SS pin is controlled by pintctrl or as a normal GPIO (like I mentioned in the question and added the sourced code where this is done). But my question is why the SPIM driver puts the SS pin as input while the pinctrl puts it as output inactive. Also, I believe a GPIO pin set as input will consume less energy compared to GPIO set as output low ?
From the dataseeht there is also this info:
The input buffer of a GPIO pin can be disconnected from the pin to enable power savings when the pin is
not used as an input


So Im kind confused what approach should be the best one to achieve a low power consumption.

Thank you!

[Miguel Ferreira]

Vidar Berg said:

SPI

Hi again,

Used the PPK and the difference is quite big.  With the CS pin being controlled by the pinctrl, basically without manually changing the CS pin to input after pm_device_action_run(<spi_dev> PM_DEVICE_ACTION_SUSPEND); 
In suspend mode it consumes 7mA.


With the CS pin being set as input after a pm_device_action_run(<spi_dev> PM_DEVICE_ACTION_SUSPEND). It consumed almost 1 mA.

[Vidar Berg]

Hi,

pinctrl only controls pins assigned to peripherals such as MOSI and MISO for SPIM, while SS is controlled as a regular GPIO by the driver. Are you cutting the power to your SPI slave IC in the suspended state? 7 mA suggests that the SS output might be back-powering your SPI sensor.

[Miguel Ferreira]

Hi,

Yes Im cutting the power from the SPI slave IC and after that putting the SPIM in suspend.

[Vidar Berg]

I see. This means that when in the suspended state, the SPI slave IC will be powered by your SS output, hence the additional 7mA idle current. The driver assumes that the IC will remain powered in the suspended state. Since this is not the case for you, you will need to patch the driver to disconnect the SS pin.

[Miguel Ferreira]

Do you know why this is happening ? What Im currently doing is basically setting as input after suspending the SPIM and it does the job.

[Vidar Berg]

I don't know which SPI slave IC you are using, but the problem is likely that you are applying voltage on the SS input when the IC is powered off, see https://www.reddit.com/r/ElectricalEngineering/comments/9fpq4i/what_does_backpowering_a_microprocessor_mean/. 

I will create a ticket in our internal bug tracker and request that we make the driver configure the SS pin as 'input,disconnect' on uninit.

[Miguel Ferreira]

Hmm I see, thanks for pointing out!
But will be a good practice on the uninit to set the SS pin as input for all situations ?
Thanks again!

[Vidar Berg]

No problem! Yes, I can't think of any scenario where you would want to keep the SS pin configured as an output after you have uninitialized the driver.

I have added this as a feature request internally. 

[Miguel Ferreira]

Cool! The NRFx SPIM driver already does this with the ss_pin

when setting it to the default value. Thanks for the support, I will close the ticket for now and if you want I can also open a PR with this changes :)

[Vidar Berg]

Vidar Berg said:

Yes, I can't think of any scenario where you would want to keep the SS pin configured as an output after you have uninitialized the driver.

After a bit further consideration, disconnecting the SS line may not be a good idea in the typical scenarios where the SPI slave remains powered in a suspended state. I will update the ticket with the feedback I get from the developers.