Strange energy leak nRF51288 with ADXL362

[puz_md]

Hi,

we are using a ISP130301 module from Insight SIP (containing a nrf51822CEAA) with a low power acceleration sensor ADXL362, connected via SPI. SoftDevice is s130_nrf51_2.0.0_softdevice.hex and SDK v11.0.0.

Problem: When we do a SPI transfer to read the acceleration data, we get a strange energy consumption pattern within 200-300 ms afterwards. Please have a look at the following current measurement, x axis ist 200 ms/div:

The very short high spike on the left side is a BT communication event (either advertising or connection) with the SPI transfer initiated (when sd_app_evt_wait()returns control to the main() loop). After the spike, the nRF51822 goes immediately back to sleep.

Approximately 80-100 ms later, while the nRF51822 is sleeping, the current into the system starts rising until it reaches a peak ~200-230 ms after the SPI transfer, and then falls again in a strange pattern. We found out that this current flows into VDD_IO from the ADXL362, this is why we expect that the memory leak is related to the nRF51822 connected to the IO pins.

As you can see from the measurement, this issue has a high impact on the average energy consumption of the system.

We observed the following behavior:

(1) If we disable the perform the SPI trasfer, we don't geht the energy leak.

(2) If we have a fast connection interval but do the SPI transfers only each ~700 ms, there will be additional "spikes" for the connection interval on top of the measurement shown. The energy leak will stay exactly the same.

(3) If we don't go to sleep in main() but wait with a while() loop, the energy leak pattern stays the same, although we get the expected current offset that is used by the nRF51822 while HFCLK and control flow are running. In other words, the problem is not related to the nRF51822 sleep mode.

(4) The SDK v11.0.0 SPI driver configures MISO with no pull. If we set it to Pull-Up after SPI initialization, we don't get the energy leak.

Does anyone have an idea on what could cause this behavior? CS on the ADXL362 is high (stable level) while the energy leak happens, so MISO should be disconnected. Also, the nRF51822 should not allow so much current to flow through a pin configuted as high impedance input.

Thanks, Michael

Update:

I know that an undefined level on input pins can lead to higher power consumption on some microcontroller architectures. But at least for a SPI Master, the MOSI pin should be tolerant to high impedance as this is a standard operating condition.

Can you confirm that the nRF5x series is robust against undefined / high impedance input levels and that the input pins have no impact on the overall power consumption?

As the current flows through the ADXL, I would conclude that the energy leak is not caused by the MOSI input pin of the nRF51822. On the other hand, MOSI on the ADXL should be a tri state circuit which should also work stable...

[Stian Røed Hafskjold]

Hi,

I've been trying to reproduce this without any luck. As long as the MISO voltage is not higher than the nRF_VDD it shouldn't flow any current. What is the VDD voltage of the ADXL362 and nRF51? Are you using the SPI SDK library in SDK 11? Are you able to post a hex file so I can try to measure it, or post some lines of code that would reproduce the issue? If you don't want to share any hex-files or code here on Devzone you can open up a confidential support case here: www.nordicsemi.com/.../Contact-Support-Team. Please remember to link to this post.

[puz_md]

Hi Stian,

both nRF and ADXK362 operate on a CR2032 lithium battery. We are using nrf_drv_spi from SDK v11.0.0. Unfortunatelly I cannot post a HEX file. But I can tell you that the problem only seems to occur with the manufactured boards and not when uswing a nRF51-SDK with a small ADXL362 evaluation board, so I can understand when you cannot reproduce the issue.

At the moment, we are going fine with configuring a pull-up on MISO, but I would like to understand how this can happen (to prevent issues in future designs). Can you confirm that the nRF I/O pins (in Input configuration) are protected against floating levels by hardware design to prevent current leaks? If this is the case, my assumption is that the ADXL362 has some internal issues. (Actually, I also had issues with this device in the past when I couldn't read correct data from the registers, it appeared like the ADXL362 did not evaluate CLK reliably back then (e.g. randomly shift two bits on one clean CLK edge)).

[Stian Røed Hafskjold]

Sorry for the late response on this. If you have a floating input you should disable the SPI by writing 0 to the ENABLE register when not active, otherwise you can get some current leaks. The driver does not take care of this so maybe a better solution is to use a pull resistor as you say. You can use an external pull with a higher value (like 1M) if the internal 13k gives you too high current consumption. But to answer your question: GPIOs are not protected against floating levels if configured as input and SPI is enabled and configured to use the input pin.