Modems exhibiting different behavior

piotr337 Any thought on what could be causing an issue with not being able to program a board?

Did you have the serial monitor open at the same time. That will cause issues with bootloader usage. Is the blue LED solid when running the load command?

SilasValera what firmware are you running? Still your application firmware? What are the values if you run at 3.5VDC on VBAT? I assume the first numbers are the identifiers for the boards?

piotr337 I ran a quick test with a different board, and that worked, then I switched back the “bad” board and it fails.

Gotcha thanks for checking. Are you strictly using the bootloader only? Is it possible you may have overwritten the bootloader?

I believe the default configuration for the newer boards is reverse the polarity that it should be for >= v5. Meaning that if you initialize the LED without those changes it’s on by default. i.e. that may not be the bootloader running but another application

Yea if you’re only using the bootloader via the onboard USB-C then that’s likely not it. Has that board been modified at all? (Headers soldered, etc)

this board has had headers soldered on it

Did you clean the headers? That was something, which costs me several days and is so far the only cause I found when I get irritating different behavior between nRf9160 feathers v5.

Just to make sure, it’s not something in the firmware, did you try the system OFF mode?

#include <modem/lte_lc.h>
void main(void)
{
 lte_lc_power_off();
 k_sleep(K_MSEC(1000));
 NRF_REGULATORS->SYSTEMOFF = 1;
}

piotr337 Yes, this board has had headers soldered on it.

Was the board working with the headers on? Its easy to bridge to another part on the board causing unforeseen issues as @AchimKraus mentions

To my very surprise:

I measured 4 feathers v5, 2 with headers, 2 without, all with PPK II and Power Profiler v4.0.0 beta 6, PPK II as power supply at 4V:

• 1 without headers => 13µA
• 1 with headers => 10µA
• 1 without headers => 130µA
• 1 with headers => 80µA

Irritating, the one with the 130µA shown by the PPK II shows sometimes even just 0,8µA (which doesn’t make sense for me).
The one with 80µA is also irritating. It starts with about 40µA and then this goes up slowly with in some seconds to the 80µA.

All in all:
I guess, without using also a joulescope, the quiescent current will be with doubts ;-).

Follow up:

The “power-off” example form Nordic seems to be not up to date and requires and additional nrf_modem_lib_init:

#include <modem/lte_lc.h>
#include <modem/nrf_modem_lib.h>

int main(void)
{
 nrf_modem_lib_init();
 lte_lc_power_off();
 k_sleep(K_MSEC(1000));
 NRF_REGULATORS->SYSTEMOFF = 1;
 return 0;
}

prj.conf:

CONFIG_LTE_LINK_CONTROL=y
CONFIG_NRF_MODEM_LIB=y
CONFIG_LOG=n

With that I’m able to measure the quiescent current using a PPK II and I get value from 1.9µA to 3.2µA for a nRF9160-DK (v1.1.0) and 5 MIKROE LTE IoT 4 Click (you need to remove the power LED, otherwise you get that 5mA).

Using that for two nRF9160 feather v5 doesn’t work that well. I get now the same 140µA for both devices with header. Before I got very different values (10µA and 80µA). I guess it need some more “switched off”. (I will try to add the code for switching of the realtime clock and the accelerometer, but that will take a while …).

I also remember, that this was my experience a year ago (not the different values between different device, just the “high value” using the “power off”). But though my app resulted in the much better values (15-20µA) I didn’t invest time into that.