Help needed for excessive standby current for SPI slave

RE: Help needed for excessive standby current for SPI slave

Ole Bauck — Wed, 27 Jul 2016 09:21:29 GMT

Hi Yano, your problem seems like an issue we have seen with other customers. If you could open a new case here on Devzone I will help you to solve the issue.

RE: Help needed for excessive standby current for SPI slave

Jim Hartmann — Mon, 25 Jul 2016 15:30:12 GMT

I resolved this issue by enabling pull-downs on MOSI, MISO, and SCK pins. I edited the file nrf_drv_spis.c to do this although it is maybe also possible to change the configuration of the pins after calling nrf_drv_spis_init()

RE: Help needed for excessive standby current for SPI slave

Yano — Fri, 22 Jul 2016 23:40:20 GMT

I'm seeing something very similar using an nRF52! SPI enabled does not increase sleep current but after a single transfer the sleep current jumps by about 300uA. Disabling the SPI has no effect. I haven't tried using pull-ups yet. Have you resolved this?

RE: Help needed for excessive standby current for SPI slave

Jim Hartmann — Mon, 18 Jul 2016 18:56:20 GMT

Hi Ole, I've since opened a support case - 30333 with more details and attached a IAR project that should demonstrate the issue.

RE: Help needed for excessive standby current for SPI slave

Ole Bauck — Mon, 18 Jul 2016 08:46:53 GMT

I tested the spi_slave example with sleep enabled (__WFE() inside for(;;){..}) from SDK 10 on nRF51 DK (PCA10028) with CSN connected to VDD and the current consumption was a couple of uA, where it should be. Have you tested the example (with sleep enabled)? What hardware are you running and what chip revision are you using (see here)?

There should be no need for pull up/down enabled on SPI.

RE: Help needed for excessive standby current for SPI slave

Jim Hartmann — Fri, 15 Jul 2016 15:11:11 GMT

At this point it appears that the nRF does not handle floating SPI inputs well (MOSI, SCK) even when CSN is high. When pull downs were enabled on MOSI, SCK, the standby current fell significantly. The 10.0 SDK initializes these pins without pull up/down enabled (see nrf_drv_spis.c). It's not unusual for a SPI Master to float SCK, MOSI when SPI is inactive, and of course the nRF SPIS floats MISO when CSN is high.

RE: Help needed for excessive standby current for SPI slave

Ole Bauck — Fri, 15 Jul 2016 12:37:11 GMT

Have you tried the SPIS example? Is the current draw the same?

RE: Help needed for excessive standby current for SPI slave

Jim Hartmann — Mon, 11 Jul 2016 14:37:06 GMT

It appears that initialization of the SPI slave is causing the excessive current draw. And calling nrf_drv_spis_uninit afterward does not reduce the current.

RE: Help needed for excessive standby current for SPI slave

Jim Hartmann — Thu, 07 Jul 2016 21:59:46 GMT

It appears that initialization of the SPI slave is causing the excessive current draw. And calling nrf_drv_spis_uninit afterward does not reduce the current.

RE: Help needed for excessive standby current for SPI slave

John — Thu, 07 Jul 2016 16:19:45 GMT

Hi Stefan, you are correct. I was not looking at the code closely enough and missed that detail. My bad

RE: Help needed for excessive standby current for SPI slave

Jim Hartmann — Thu, 07 Jul 2016 16:11:55 GMT

This was also my understanding of how it is supposed to work. We initially had "true" (high accuracy) and the current was higher. Disabling high accuracy lowered the current significantly but not to the level we need.

RE: Help needed for excessive standby current for SPI slave

Jim Hartmann — Thu, 07 Jul 2016 16:10:43 GMT

Yes thanks, I've gone through the current consumption guide thoroughly and finally decided to post here because I feel I've tried everything. I will try incrementally disabling initialization as you suggest.

RE: Help needed for excessive standby current for SPI slave

Stefan Birnir Sverrisson — Thu, 07 Jul 2016 15:55:21 GMT

correct me if Im wrong John, but I was under the impression that using

GPIOTE_CONFIG_IN_SENSE_LOTOHI(false);

uses the PORT event, which is low current, while the

GPIOTE_CONFIG_IN_SENSE_LOTOHI(true);

would use the GPIOTE IN events, which are high current.

Seems like jhartmann is using the former.

RE: Help needed for excessive standby current for SPI slave

Stefan Birnir Sverrisson — Thu, 07 Jul 2016 15:50:54 GMT

Hi jhartmann

Have you looked at the nRF51 current consumption guide, troubleshooting section? That could give some hints. As stated in the nrF51 current consumption guide, the current consumption of the nRF51 SPIS should be very low when CSN line is set high, i.e. when the SPI master is not transmitting.

I have seen high current consumption in the past when trying nRF51 SPIS connected to SPI master. That was because the nRF51 was powered through the SPIS configured GPIO pins (from the SPI master device) and did not power reset when I cut power from the board. I had to disconnect the SPIS pins from the SPI master, power reset, then connect the SPIS and SPI master together again. It is anyway also possible to reset the nRF51 with the command

nrfjprog --pinreset

so you dont need to disconnect the SPIS. Perhaps that does not apply directly to your case anyway as lack of reset after programming should add ~1mA but not the ~300uA that you are seeing.

I have tested the SPIS current consumption when connected with another board that runs SPI master in SDK 11.0.0. It is low current. For that to happen, I have disabled constant latency mode and disabled logging. I have tried SPIS current consumption in older SDK versions and it has been low current as well.

So my question, have you tried standard SPIS example in SDK 10 without softdevice, in order to see if you get low current consumption?

Perhaps you can incrementally comment out initialization code in your example to see when you get the desired current consumption. That way you can narrow down what the source of the high current consumption is.

RE: Help needed for excessive standby current for SPI slave

John — Thu, 07 Jul 2016 13:49:42 GMT

It looks like you are using the GPIOTE IN event to wake your device. This is known to burn a lot of power on the nRF51822. You should use the PORT event instead if you need a lower power solution. Search this forum and you'll find a lot of information on how to do this.