Serial LTE Modem app in NCS main has unexpected power consumption after #XSLEEP=2

Hi Michal,

michalm said:

We can not test on unmodified nRF9160DK, because it does not allow automated testing in repetable way (testing by test scenarios without manual intervention). The modifications are only to allow automated testing.

I understand that you're wanting to test this in your application space, but we are now hunting an issue that causes your overall current consumption to rise. That will require to look exactly at specific features of the firmware and hardware setup, to try to isolate the issue, and thus pin-point where it originates from. This will include things like testing manually, and possibly physically disconnecting IOs while watching the current consumption for any change.

michalm said:

we are testing NCS main because we were asked by NordicSemi (Lorenzo Amicucci) to do so.

And that is why I reported several issues here from NCS main (nRF9160 test scenarios) - Lorenzo asked me to do so.

In the future, I would recommend that you use "git cherry-pick" to pick specific commits on top of a tagged release. This gives you much better control of the code base.

Could you please try the below steps?

1. Add the nrf_gpio_cfg_default() loop as I previously described to see if this has an impact on the sleep current?

2. If the above mentioned nrf_gpio loop does not help, can you please test manually, by removing your HW modifications that goes directly to the nRF9160 one-by-one?

Kind regards,

Håkon

Hi Håkon,

we are quite on opposite side, we try to use minimal HW setup (as simple as possible) who allow automated test scenarios for nRF9160/SLM.

That is why we use nRF9160DK in this setup https://docs.google.com/document/d/1HuWBlC9k0IS1NcfX7aGUEJqAxwaqZV2D8SHFDCM0CXs/edit?usp=sharing

We're far far far away from application space https://www.hardwario.com/chester/

Automated tests are necessary to be able to do 100% reproducible testing and to be able to test all required functionality for nRF9160/SLM for every NCS relese/fixes.

That allows us to make tests directly comparable for any NCS SW release without human errors and with possibility to test all critical functionality. Manual intervention is not option for stability and testing reliability.
We could not afford to deliver faulty parts of our products, automated functionality tests (including power consuption) is key to hold decent quality.

If you have proposals how to make better setup for automated testing, advice please.

What is your setup for automated nRF9160/SLM functionality testing please (quality assurtance) ?

I do not see reasonable way how to simplify (or remove modifications) test setup described above.

nrf_gpio_cfg_default() loop does not help.

Kind regards,
Michal

Hi,

michalm said:

Manual intervention is not option for stability and testing reliability.

For a final product test jig, I agree.

However; you are trying to address leakage in current in your system as a whole. Running the same firmware on a stock nRF9160-DK does not show this issue, while running it on your modified platform does. You have to incrementally go from either "bad" to "good", or from "good" to "bad" state in order to identify which specific feature/pin/signal causes this leakage. This will require either removing or adding your hw-modifications in a step-by-step procedure to find the root cause.

michalm said:

nrf_gpio_cfg_default() loop does not help.

This indicates that the issue is either the UART pins, or something external to the nRF.

If your USB-to-UART converter is running on 3.3V, and the nRF9160's VDD_IO is 3.0V, there can be smaller leakage through this connection (ie. the ESD protection inside the nRF pads, or in the pull-ups). 

If the ext. UART converter is 3.3V, VDD_IO is 3.0V, that gives a diff. of 0.3V potentially through a pull up of ~13k:

0.3V/13k = 23 uA. This corresponds with your measurements of approx. 25 uA.

Could you check this?

Kind regards,

Håkon