Hello all,
I'm using the NTC in a resistor divider configuration according to the datasheet (Figure 21) in my design. It seems that the SDK enables the resistor divider by applying power to P1_4 with the following code in hw_usb_charger.h:
if (dg_configBATTERY_CHARGE_NTC == 0) {
/* Set P14 to output high (3.3V). */
GPIO->P1_PADPWR_CTRL_REG &= ~(1 << 4);
GPIO->P1_SET_DATA_REG = (1 << 4);
GPIO->P14_MODE_REG = 0x300;/* Set P16 to input, no pull-up or pull-down. */
GPIO->P16_MODE_REG = 0x0;
}
However, I didn't find any code where this gets disabled again. This makes me wonder if my design will drain roughly 160uA of current just for this 20k resistor divider permanently? That would hardly be acceptable...
Am I missing something? Or is this NTC stuff only designed for batteries "large enough so that 160uA should not matter"?
Greetings,
Roland
Hi roland237,
You do not need to re-configure P1_4/P1_6 in order to avoid leakage current. Please download the below document and take a look at6.1 High current consumption in sleep modewhen using NTC paragraph. In the document, you will find a workaround to avoid leakage current in sleep mode when using NTC..
https://support.dialog-semiconductor.com/resource/known-sdk-tools-issues
Workaround to this is to change apply_wfi as follows:
/*
* Mark that a wake-up interrupt will be treated as such and not as a
* typical interrupt.
*/
pm_system_sleeping = sys_powered_down;
/ /如果启用了ntc,配置P1_4 / P1_6 avoid leakage current
#if 0==dg_configBATTERY_CHARGE_NTC
hw_gpio_set_pin_function(HW_GPIO_PORT_1, HW_GPIO_PIN_4, HW_GPIO_MODE_INPUT_PULLDOWN, HW_GPIO_FUNC_GPIO);
hw_gpio_set_pin_function(HW_GPIO_PORT_1, HW_GPIO_PIN_6, HW_GPIO_MODE_INPUT_PULLDOWN, HW_GPIO_FUNC_GPIO);
#endif
Thanks, PM_Dialog
Hello PM_Dialog,
OK, thanks, this is exactly what I was looking for.
Actually I did read the "issues" document some time ago, but didn't remember this one when I stumbled across the NTC thing.
It seems that this issue is well documented (if one knows where), so may I suggest you incorporate this fix in the next SDK release? Because the workaround basically means patching the SDK locally. It is very likely that a change like this might introduce a regression if you release a new SDK which has the bug in it again.
Greetings,
Roland
Hi roland237,
Glad you figured your issue out. I will suggest to the SDK team to incorporate fix in the next SDK release.
Thanks, PM_Dialog