52 Series Deep Sleep Power Consumption Issue

Troubleshooting
1

Help needed: I’m using the 52 series chip. In the board-level file, I initialized I2C as follows:

HAL_PIN_Set(PAD_PA29, I2C2_SCL, PIN_PULLUP, 1);
HAL_PIN_Set(PAD_PA30, I2C2_SDA, PIN_PULLUP, 1);

After entering deep sleep, the measured power consumption is 1.45mA. After commenting out this initialization code, the measured power drops to 0.97mA. How can I resolve this issue? Should I add a disable function inside the BSP_IO_Power_Down() function?

Additionally, the 0.97mA current consumption after entering deep sleep still seems relatively high. It differs significantly from the documented values of LPSYS: 93uA and HPSYS: 316uA. What could be causing this discrepancy? Any help would be greatly appreciated. Thank you.

2

The deepsleep power consumption of the 52x chip should be on the order of 20μA. The documentation you’re referring to might be for the 55x or another chip.

If the power consumption is higher than expected, start with a board-level breakdown to eliminate power drawn by peripheral components. Then, check for issues related to IO configuration.

Specifically regarding I2C, entering deepsleep does not change the IO state—the I2C pull-up resistors remain active. If the external I2C device has its power turned off, this could lead to leakage current through the IO pins.

3

Alright, thank you for the reply. I was referring to Table 3-1: “Low-Power Modes → Chip Current” in the Low-Power Development Guide - SiFli-Wiki v1.0, but it doesn’t mention which chip this table refers to. Could you clarify which chip this table describes?

I see that the 52-series chip can go down to 20μA. Currently, I’m suspending the main thread and using the PA34 key to wake it up. This should put the chip into deepsleep mode, right? Below is the log output. :thinking:

msh />[pm]S:3,2230
[pm]W:154301
[pm]WSR:0x2
gpio_wakeup_handler!
[pm]S:3,154325
[pm]W:247899
[pm]WSR:0x2
gpio_wakeup_handler!
[pm]S:3,247921
4

:pleading_face: Do you have any code? I’d like to learn how to put LVGL into sleep mode.

1 Like
5

Which routine was this modified from? Is the small core running? There’s a dual-core routine in the main branch that includes Bluetooth, sleep, and LVGL functionality.

SiFli-SDK/example/get-started/dualcore at main · OpenSiFli/SiFli-SDK

You can also refer to this simpler pm example below:

SiFli-SDK/example/rt_device/pm at main · OpenSiFli/SiFli-SDK

1 Like
6

Hello, I modified the RTT project based on hello_world, and I think I’m not using the coprocessor (small core), right? I referred to the PM example program
(https://github.com/OpenSiFli/SiFli-SDK/tree/main/example/rt_device/pm), and only added PA34 as a wakeup source. Below is the main program:

static void gpio_wakeup_handler(void *args)
{
    // rt_pm_request(PM_SLEEP_MODE_IDLE);
    rt_kprintf("gpio_wakeup_handler!\r\n");
}

void gpio_wakeup_config(void)
{
    int8_t wakeup_pin;
    HAL_PIN_Set(PAD_PA34, GPIO_A34, PIN_PULLDOWN, 1); // set PA34 to GPIO function

    HAL_HPAON_EnableWakeupSrc(HPAON_WAKEUP_SRC_PIN10, AON_PIN_MODE_POS_EDGE); // Enable #WKUP_PIN10 (PA34)

    rt_pin_mode(BSP_KEY1_PIN, PIN_MODE_INPUT);

    rt_pin_attach_irq(BSP_KEY1_PIN, PIN_IRQ_MODE_RISING, (void *) gpio_wakeup_handler, (void *)(rt_uint32_t) BSP_KEY1_PIN); // PA34 GPIO interrupt
    rt_pin_irq_enable(BSP_KEY1_PIN, 1);
}

int main(void)
{
    rt_kprintf("Power Consumption Test!\n");
    
    gpio_wakeup_config();

    // while (1)
    // {
    //     rt_kprintf("__main loop__\n");
    //     rt_thread_mdelay(5000);
    // }
    return 0;
}

After power-up, it immediately enters sleep mode and there is serial output. I suspect it might still be an issue with my IO configuration.

7

If you need to enter sleep mode within LVGL, you can refer to Xiao Zhi’s code and use the GUI state machine to suspend the thread and enter sleep mode.

8

If the small core is not running, it won’t enter sleep mode, resulting in additional power consumption. The two cores sleep independently; actions taken on the big core only put the big core to sleep. If Bluetooth functionality is not needed and the small core does not need to be started, you can refer to this line of code in pm_gpio and call HAL_LPAON_Sleep to directly put the small core into sleep mode even when the small core is not started.

https://github.com/OpenSiFli/SiFli-SDK/blob/76000ad84d379a369a604658773b50afb3e36e24/example/pm_gpio/src/main.c#L42

9

rt_device/pm is a dual-core project, and the SConstruct file includes the small core project in the compilation.

https://github.com/OpenSiFli/SiFli-SDK/blob/76000ad84d379a369a604658773b50afb3e36e24/example/rt_device/pm/project/hcpu/SConstruct#L20

Meanwhile, the incremental proj.conf configuration under the 52x directory also enables Bluetooth, ensuring Bluetooth operates normally. After the small core is started, it will automatically enter sleep mode.

10

I see, thank you so much! Indeed, the issue was that the small core wasn’t sleeping. After removing all peripheral devices, the Deep Sleep current dropped to only 50μA :face_blowing_a_kiss:. There are still a few microamps introduced by other chips, so theoretically it could be even lower.

So, in a real application where Bluetooth functionality is used, can we still call HAL_LPAON_Sleep() to put the small core into sleep mode?

Also, I have another question: Currently, my I2C pins are configured as floating, resulting in a power consumption of 50μA. If I internally pull up SCL and SDA using HAL_PIN_Set(PAD_PA00, I2C1_SCL, PIN_PULLUP, 1);, according to what pengwei mentioned earlier about possible IO leakage, even removing the chip still results in about 0.77mA of power consumption, which is quite strange.

Therefore, I tried using the 3.3V output from the chip’s LDO3 to externally pull up the I2C lines, but there’s still 0.44mA of current draw. It’s quite a tricky issue—would appreciate any advice :smiley:

11

I didn’t understand your description. First of all, pulling up the I2C pins does not introduce the chip’s own leakage current. If leakage occurs, it’s usually caused by the external circuit connected to the pulled-up IO—such as other devices connected externally being powered off. You need to analyze the hardware schematic and troubleshoot all connections related to the relevant IO.

12

Alright, got it. I’ll try removing the external circuit :ok_hand:

14

Indeed, it was due to the external circuit, as the pull-up resistor was not removed, causing a leakage current. Thank you :saluting_face:

15

If Bluetooth is used, meaning that the small core project has been included and the large core has enabled Bluetooth as in the rt_device/pm example, there is no need to call HAL_LPAON_Sleep to put the small core into sleep mode. After the small core starts, it will automatically sleep and wake up according to Bluetooth behavior.

16

For I2C, if there is a stable external pull-up/down resistor, it should be configured as NOPULL. If the external power supply is disconnected during sleep mode, it should be configured as PULLDOWN.

17

Got it, got it, thanks for the guidance :face_blowing_a_kiss: