1mA active mode troubleshooting

RE: 1mA active mode troubleshooting

Ole Bauck — Tue, 08 Mar 2016 16:25:29 GMT

I would recommend to migrate to a newer SDK, but understand that this may be too much work. I don't know of any critical issues with this SDK + SD, other than that the PWM have a high probability of inverting when used with SD. This was fixed in SDK 10.

RE: 1mA active mode troubleshooting

Ole Bauck — Tue, 08 Mar 2016 16:21:04 GMT

app_gpiote and app_button should only use gpiote PORT event. You can check the NRF_GPIOTE->CONFIG[n] register field MODE to see if gpiote IN event is used. For sharing the code confidentially with Nordic Support you can make a new case on MyPage. Mark the case with my name.

RE: 1mA active mode troubleshooting

loren — Tue, 08 Mar 2016 16:21:04 GMT

Also, is there any chance that we're running into issues as a result of this set of versions (S110 7.3, SDK 6.1.0)? We chose these initially because it seemed like the best choice to support Rev2 and Rev3 chips, but at this point we have no requrirement for Rev2 support. However, moving to a newer S110 and SDK appears to require some substantial work, so we're hesitant to do that unless there are known issues we might be resolving related to this problem.

Thanks again,

loren

RE: 1mA active mode troubleshooting

loren — Tue, 08 Mar 2016 16:17:38 GMT

Hi Ole,

I think that we are only using the GPIOTE PORT -- but we are just using the app_button and app_gpiote so it's possible that they are misconfigured somehow. Are there registers we can read to confirm that the gpiote IN is not in use?

If there a way that we can confidentially share the code with you that would be helpful.

Best regards,

loren

RE: 1mA active mode troubleshooting

Ole Bauck — Tue, 08 Mar 2016 16:09:19 GMT

Are you using gpiote IN event? This will request the HFCLK. There is no way to know what is using the HFCLK programmatically. Would it be possible to upload code so that I can reproduce it on a nRF51 DK?

RE: 1mA active mode troubleshooting

loren — Tue, 08 Mar 2016 14:52:05 GMT

Hi Ole,

We are using SOFTDEVICE_HANDLER_INIT(NRF_CLOCK_LFCLKSRC_XTAL_100_PPM, true);

The hardware is custom, but the chip is rev 3 and we see the problem on both QFAA and QFAC parts.

We are disabling PWM when not in use, but because of the known issue with PWM we also went to the trouble of completely removing from the build, and still see the problem. It would really be nice if there was some way to programatically determine what is using the HFCLK resource.

Thanks again for your help.

RE: 1mA active mode troubleshooting

Ole Bauck — Tue, 08 Mar 2016 14:45:06 GMT

I guess you are disabling the pwm or else this would keep the timer running (which requires HFCLK). What clock source are you using in SOFTDEVICE_HANDLER_INIT()? What hardware are you running (PCA...)?

RE: 1mA active mode troubleshooting

loren — Tue, 08 Mar 2016 14:11:51 GMT

Hi Ole,

Thanks for your quick response. We are using:

TWI, but we stop it (NRF_TWI1->ENABLE = 0;) after use. GPIOTE for app_button and waking up the system; ADC for infrequent periodic measurements, but we stop (NRF_ADC->TASKS_STOP = 1;) after each measurement PWM using nrf_pwm.c with the PAN73 workaround described here

We have also tried removing each of these from our firmware but still see the baseline.

We are also using: app_timer app_button app_fifo app_gpiote app_scheduler

loren

RE: 1mA active mode troubleshooting

Ole Bauck — Tue, 08 Mar 2016 09:57:59 GMT

Sounds like something is requiring the HFCLK, you can see which resources need it in the "block resource requirements" table in the Product Specification, part 8.3.

Task registers like NRF_POWER->TASK_LOWPWR are only used to set a task, so the register will be cleared after. Therefore there is no use in reading it. You can try with NRF_POWER->TASK_LOWPWR = 1 and see if the current consumption decreases.

What SDK peripherals are you using?

RE: 1mA active mode troubleshooting

loren — Tue, 08 Mar 2016 08:02:22 GMT

Also, we notice that the current in the system does drop down into the ~uA range every 1.4 seconds, for about 10ms. This time doesn't obviously correspond to anything in our firmware -- could this be something in the SD, or a clue to what's going on with our 1mA baseline?