Peripheral_server_sleep overconsumption

[rvs]

I have tested the peripheral_server_sleep sample application on the RSL10 evaluation board to check the lowest consumption possible while advertising every 5s. As explained by the readme_peripheral_server_sleep.md of SDK3.5, the default configuration has to be modified:

• CFG_ADV_INTERVAL_MS=5000
• .rteconfig uses the release_light variant of the BLE stack and Kernel libraries components
• CFG_LIGHT_STACK
• CFG_CON=1
• Default link file replaced by sections_light.ld

No other change has been made (so we use the default Tx Power 0dBm, the default internal voltages and so on…).

Once flashed, the hardware straps are modified as described by KB: RSL10 Power Consumption Evaluation Guide and quickly summed-up by the red modification below:

We can see an extremely low consumption (even lower than expected) when powered at 3V:

But from time to time (approximately every 1 or 2 minutes when powered at 3V) we have a consumption ~1000x higher whereas no BLE device has connected. What is strange is that this high consumption is stable during exactly 5s - corresponding to the advertising interval:

I also noticed that this overconsumption becomes much more frequent when the board is powered at 2V (and even more when powered at 1.5V).

Could it be due to an internal tension that is configured slightly below what is supported?

It isn’t easy to diagnostic as we can’t debug (due to the sleep). I have noticed something that seems a bit strange: in rsl10_sys_power_modes.c the function Sys_PowerModes_Wakeup needs from time to time several seconds to execute, and the ‘blocking’ line is:

/* Wait for SYSTICK interrupt (to power up flash as late as possible) */
SYS_WAIT_FOR_INTERRUPT;

Isn’t it abnormal? It seems to me that the code executed from Wakeup_From_Sleep_Application up to entering Main_Loop should always be fast when advertising. Isn’t it correct? Even if strange, it’s not the direct cause because it occurs more frequently than the overconsumption and its duration is not 5s (it is ~3s).

I suspected a hardware problem on the evaluation board, but I confirmed the problem on a second board, so I guess it is reallys a software issue…

Any idea? Thanks in advance.

[rvs]

The problem remains although I made some improvements…

First, I made a bad diagnostic in my description (and I haven’t the rights to modify this previous post): Sys_PowerModes_Wakeup is not blocking!

Because we cannot debug, I tried to use the LED but:

• I was not aware of the subtilities of PADS retention (see PADS retention at wakeup for details)
• You cannot configure DIO6 as an output set to 1 too early and turn off pads retention or it resets!

This later point is very annoying, and I don’t know the root cause. The following lines set the LED + DIO 4 and 5:

/* Turn LED on */
Sys_DIO_Config(LED_DIO, DIO_MODE_GPIO_OUT_1);

/* Disable DIO4 and DIO5 to avoid current consumption on VDDO */
Sys_DIO_Config(4, DIO_MODE_DISABLE | DIO_NO_PULL);
Sys_DIO_Config(5, DIO_MODE_DISABLE | DIO_NO_PULL);

/* Turn off pad retention */
ACS_WAKEUP_CTRL->PADS_RETENTION_EN_BYTE = PADS_RETENTION_DISABLE_BYTE;

I can move this code early, but not too early within Sys_PowerModes_Wakeup otherwise I get a reset (probably caused by the watchdog).

I noticed the problem is not due to turning off pads retention too early but rather to calling too early Sys_DIO_Config either on DIO 6 (LED), 4 or 5. That’s a big problem because if we can’t debug and can’t use DIO we become blind!

To come back to my overconsumption, I have noticed that when modifying CFG_ADV_INTERVAL_MS (2000 instead of 5000), the overconsumption duration follows also!

[rvs]

The problem seems so strange that I have installed SDK3.5 on another PC (on which no other ON Semi SDK has ever been installed). I confirm I also have the same problem when generating on this PC.

I have attached 3 files corresponding to the 1Mbps version of peripheral_server_sleep with an advertising of 5s and a RF amplifier set to 0dBm, +3dBm and +6dBm.

peripheral_server_sleep_1mbps_5s_0dbm.hex (419,8 Ko)
peripheral_server_sleep_1mbps_5s_3dbm.hex (419,8 Ko)
peripheral_server_sleep_1mbps_5s_6dbm.hex (419,8 Ko)

Because the tests have also been done on 2 different RSL10 evaluation boards, I really think there is a problem in the sample application code. My feeling is that BLE_Power_Mode_Enter(&sleep_mode_env, POWER_MODE_SLEEP); enters correctly sleep mode most of the time, but from time to time it doesn’t and the consumption is much higher than expected (but stable to a high value making me think that the CPU is indeed sleeping but a pin - internal or external - might leak current).

This overconsumption becomes more frequent when the input voltage decreases.

[martin.bela]

@ rvs

We have confirmed this issue on our end and will have to take a look with the Stack Experts to determine a cause and apply a fix. Images outlining our confirmation are attached. Thank you for reporting this bug. For the time being, we suggest developing with the Non-Light stack variant (the only determent being a slightly higher sleep current [~15-20 nA]) as it does not encounter the problem.

---

Non Light Stack

---

Light Stack

[martin.bela]

@rvs
The hardware team and our engineer have managed to find the root cause of this issue, but are still working on finding a fix for the Light Stack.

It seems that this issues is caused by leaking DIO Current when the Light Stack is used. For an unknown reason, this DIO Current leak does not occur when the Full Stack is used.

If you would like to continue to use the Light Stack during development, you can get around this current leak issue by:

1. Commenting out the DIO LED toggling done on line 102 of the ‘ app.c ’ file and on line 299 of the ’ app_process.c' file.
2. Changing line 27 of ‘ app.c ’ from ‘ Sys_DIO_Config(LED_DIO, DIO_MODE_GPIO_OUT_1); ’, to the following, ‘ Sys_DIO_Config(LED_DIO, DIO_MODE_DISABLE); ’.

[rvs]

I confirm the proposed modification seems to fix the problem (or at least makes it rare) when powered above 2.2V.

But the problem remains when the input power is below 2.2V.

I guess the problem is not specific to DIO 6 (i.e.: the DIO controlling the LED on the RSL10 evaluation board), so any DIO used as output could potentially cause a similar problem.

Even worst, the RFFE is interfaced internally with the CM3 through 10 DIO (See Table 10 below extracted from the RSL10 Hardware Reference §8.3) that could also be affected by this problem (I assume).

I imaging the bug comes from BLE_Power_Mode_Enter that manages the sequence leading to sleep mode. The code is proprietary, so we can’t investigate anymore as simple user…

The bad news is that this problem is not specific to CFG_LIGHT_STACK: I could reproduce it with the full stack version, but only below 2.2V. In fact, the light stack with the fix behaves like the full stack version as summed up here:

Input voltage	Light stack	Light stack with fix	Full stack
Below 2.2V	overconsumption	overconsumption	overconsumption
Above 2.2V	overconsumption	OK	OK