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.