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

[rvs]

There are two distinct problems that looked similar and my conclusion was biased. After several days of test (and the help of @martin.bela and @rastislav.stefun) I can clearly report the 2 issues:

Overconsumption affecting exclusively the light stack

When using CFG_LIGHT_STACK there is from time to time an overconsumption that seems to be linked to DIO usage.

Solution:

• Use the full stack (that isn’t affected by this bug)
• If you still use light stack:
  • As a workaround, don’t use DIO (if it is possible),
  • Or wait for the real fix of light stack that should be solved by SDK 3.6 - TBC by OnSemi

Test bench issue when measuring current at low voltage

At low voltage, the RSL10 evaluation board configured for current measurement (strap settings as described by KB: RSL10 Power Consumption Evaluation Guide) may reset from time to time (not due to watchdog, just because the RSL10 power falls temporarily), but this depends on your test equipments (power supply, amperemeter, cables) and on the way you use the board.

Here is the description of a test that shows this hardware problem (partly linked to the test bench and partly linked to the RSL10 board).

• Connect the power supply + amperemeter in serie on EXTERNAL POWER connector
• The peripheral_server_sleep is:
  • Stable above 2.2V
  • Still running at 2.1V but we experience reset frequently
  • Completely unstable at 2.0V or below (always reset after first advertising)

Then we soldered C43 on the RSL10 board which is the 4.7µF capacitor decoupling VEXT. We then noticed the same behavior but the threshold is below (1.9V provides the same stability level with C43 as 2.1V without C43).
When soldering a 10µF on C43 this stability threshold becomes 1.8V.

At this point (C43 present with 10µF) we made an interesting discovery: when the amperemeter is connected before VEXT the stability threshold is at 1.8V whereas when the amperemeter is connected on P3 (CURRENT MEASURE connector) the stability threshold is at 2.2V which proves our amperemeter is intrusive (even though it isn’t a low-cost one: we use a KEITHLEY DMM7510).

Conclusion:

• The RSL10 evaluation board configured for current measurement may not work at low voltage (the threshold depends on your test equipments)
• In case of reset, solder C43 and don’t use P3 (connector for CURRENT MEASURE)

ON Semiconductor should report this warning because the capacitors embedded on the board are too weak if you power the board at low voltage with (an intrusive) amperemeter!

[brandon.shannon]

Hi @rvs,

I am glad to hear that you were able to confirm the Light Stack behavior was linked to DIO usage, similar to what our tests concluded on our end. We have passed this on to our internal design team who will hopefully be able to address the bug and provide a fix in future releases. As this process moves forward, we will keep you informed of any updates to the status of the bug.

To acknowledge the Amperemeter, and Capacitance suggestions you have in the second section, while we are completely open to adding a warning/statement outlining the limitations to our documentations, we would first like to better understand the problem and the possible solution that you suggest.

The main concern is that seeing a voltage drop over an amperemeter added in series with a power supply is usually the expected behavior. While adding a larger capacitor could help negate the effects this has on low power operations, we are not sure that this is an issue we can report for RSL10, or if it would be an issue with testing equipment that we could warn against. Do you have any further details about the setup or suggestions that might help us determine the most effective way to address this limitation?

[rvs]

Hi @brandon.shannon,

I didn’t measure the voltage drop on the amperemeter. I can just provide information on my test bench that used “standard equipment”:

• Power supply: SIGLENT SPD3303X (with current limitation set to the max level)
• Amperemeter: KEITHLEY DMM7510 (clearly intrusive when measuring low current)
• Cables not as short as they should be

My view is that it isn’t an RSL10 problem but rather a problem linked both to the RSL10 evaluation board hardware (capacitor too weak) and the test bench (intrusive amperemeter, current limit of the power supply, cables).

I am surprised your test bench allows a normal behavior at 1.8V with the standard board but I guess it won’t work anymore at 1.5V whereas it should!

Because the RSL10 evaluation board provides the straps allowing measuring the consumption at different voltage, it seems normal we can experiment the whole range of valid input voltage… at least a warning would help as I didn’t suspect such a problem while the input voltage is ~1V above the minimum value.

Regards

[brandon.shannon]

Hi @rvs,

You are correct that when we measure using our two setup (first is a Souremeter and the second is an External Power Supply with a Amperemeter on the P3 Current Header) we have not experienced this reset behavior anywhere above 1.25V when using the Buck or LDO as needed.

I think we still need to do some debugging on the hardware setup to determine how we can acknowledge this on our end so others do not experience the same issue.

As the next step, can you please measure the VBAT voltage that reaches the RSL10 during these resets? We would like to determine if there is any sort of voltage drop-outs over your intrusive amperemeter that might cause the VBAT to drop below acceptable levels.