RSL10 current consumption during wakeup/advertisement event

I am trying to understand the various phases of a wakeup/advertisement event with the hope of further reducing the power consumption. I have attached the current measured during one advertisement event. Can someone please explain what the various phases are and if the measured currents look accurate? (current was measured using the P3 header in the RSL10 eval board running the periperhal_server_sleep application)

Also I see 1 KHz current spikes throughout as seen in the image. Is this from the RSL10 or something else from the eval board?



Below is the picture which offers high-level insight into the components of the advertising event itself and the parameters in the RSL10 HW and BLE SW that will have the most effect on each component.

As an example is attached a screenshot of one of our own current measurements that was done to characterize the RSL10 advertising event.


Mentioned ‘1 kHz current spikes’ are not something that are usually encountered during normal operations. They could be related with your hardware setup. Please double check your EVB Jumper setup. To achieve the lowest current measurements, you should:

  • Remove the 3 SWD Jumpers
  • Remove the P8 and P7 jumpers
  • Place the Power jumper VBAT
  • Place the P9 jumper on VBAT
  • Place the P10 jumper on BATT

If the problem remains, please share more detail on your measurement setup, so we can help to debug it.

Thank you for cooperation and for using our Community Forum.

Thanks for sharing these information, my current measurements align very well with yours. Also the 1 KHz spikes disappeared once I removed the VDD_AT P8 jumper. I have a couple of follow up questions:

  1. From my measurements, the peak Tx current (with 3.3V VBAT) is around 4.5 mA which matches the datasheet. But the peak Rx current is 4 mA instead of the 3 mA in the datasheet. What could be the reason for that?

  2. I have attached the current measured during one connection event which includes a notification packet (peripheral_server_sleep with 15 byte notification enabled for the custom service). The total duration is around 5 ms. Do you have any suggestions to shorten the active duration, like increasing the CPU freq or modifying any wakeup parameters etc so that the avg power can be reduced?


These higher than expected peaks you are seeing could be caused by the large current spikes occurring across the interval. As can be seen in the screenshot we shared, this event should not have the large current spikes during the setup and teardown phases, and I am wondering if these same spikes are present during the TX/RX portions. Based on our screenshot, the TX peak at 3V was measured at ~3.5mA and the RX peak at ~2.5mA. Can you please share more information about your setup and measurement equipment? Is it possible to use a Source Meter to instead measure the current directly through the VBAT header? Thank you for cooperation.

In general, our BLE samples are already running on the 48MHz XTAL and the wakeup process is already optimized. Other than verifying that the System Clock Prescale is set to 1 (resulting in 48MHz SYSCLK) and possibly sending a 2 Mbps PHY request (this will reduce TX/RX time but will increase current), there is not anything that can be done to reduce this Connection Event time.

Note: In our next RSL10 Software CMSIS Package release, we will be including an update to allow the user to set the MD bit. This will allow your 15 byte notification to be packed together with the Connection Event, resulting in a single, longer TX/RX segment. When this is available, you will be able to choose a higher average current paired with a shorter Connection Event, which in our evaluation has resulted in a low Energy consumption over the Connection Event.

Thank you for using our Community Forum.

Thanks for the response.

Comparing your screenshot with mine, it looks like my measurement has a higher resolution and hence there are HF oscillations during Tx/Rx while your measurement seems to represent an average of those. In fact, when I average my measurement, the Tx and Rx currents are close to 3.5 and 2.5. So I’m guessing the peak of those oscillations is Tx/Rx current + CPU current.

That’s great, I did not know it was possible to combine those packets. I’ll look forward to the next release.

The peripheral_server_sleep by default was using 8 MHz SYSCLK. I updated the RFCLK_FREQ to 48000000 in app.h but now the MCU resets randomly (sometimes as frequently as 1s) at the end of an advertisement event. Doesn’t happen with 16 MHz and happens less frequently with 24 MHz. I haven’t changed anything in the sample code. Is this a known issue?


The peripheral_server_sleep was tested using the same 48 MHz modifications and similar reset issue has not been recorded.

Since you provided that no changes in the sample code were made, probably the hardware setup is different. Are you measuring using a Source Meter through the VBAT header or are you using a Power Supply on VBAT and a Meter on the Current header? Does this reset happen when the device is run without the measurement equipment? It is curious if the measurement hardware itself is causing the reset.

As a quick trial, you can also try setting the TWOSC variable in ‘app.h’ to 2000, as this has been know to offer better stability in our peripheral_server_standby sample code when >16MHz SysClk is used, but this has never been reported in our peripheral_server_sleep sample code.

Thank you for cooperation and for using our Community Forum

This reset issue occurs even without the current measurement hardware, with just the eval board powered from usb.

I changed TWOSC to 2000 but this made it worse as the reset occurred soon after the first adv packet consistently. But reducing TWOSC to 1000 or 500 did not solve it either.

This issue is not occurring with the peripheral_server_standby, so the problem seems to be with sleep mode. The reset occurs exactly at the end of an adv event but it is difficult to say if it is before or after the device goes to sleep.


If you haven’t make any changes in the software or haven’t altered 48 MHz SYSCLK, probably the problem is hardware related.

Could you please provide which RSL10 evaluation board you are using with your jumper setup? Also please provide CMSIS version you are using.

Thank you for cooperation and for using our Community Forum.

I am using the EVBUM2529/D. Here is the jumper setup:
P4 - USB
P8 - 3.3V
P7 - REG
P10 - 3.3V

CMSIS version is


Could you please upgrade to our latest RSL10 CMSIS Pack. Could you also provide more specific details regarding how you are determining that a restart is occurring? What exactly are you seeing?
Usually, a restart is encountered by an ~8s lock-up, followed by a Watchdog reset.

Thank you for cooperation and for using our Community Forum.

I am using the latest CMSIS pack 3.4.2 released on September 2020 though the “PACK_REVISION” says Is there a newer version that I am not seeing in the downloads page?

The LED that is supposed to blink during every advertisement event stops blinking for a while before resuming. During that time I do not see the advertisement packets in the packet sniffer I am using. Also if I monitor the current, I can see that the device resets right at the end of an adv event following which I see several seconds of continuous activity before going to sleep, similar to what happens during a boot. And the duration for which it is advertising before resetting is random, as short as 1s and as long as 20s.


CMSIS Pack version 3.4.2 is the latest pack version.

Have you changed any of the firmware that is stored within the CMSIS Pack installation directory? The sample applications will automatically import all of the necessary ‘background’ files into the RTE/ directory within the project, but some are copied locally and some are referenced from within the CMSIS Pack. If you have changed any of these files when working on a different project, the changes will carry over.

It would be useful to uninstall the RSL10 CMSIS Software Pack (3.4.2) from Eclipse, delete any residual files from the CMSIS Install directory, and perform a fresh installation of the pack. This will at least guarantee that we are aligned at the same software level, and we can look into the hardware further.

Maybe it would be helpful trying to load one of the demo projects. It would be a good baseline to ensure that your setup is correct. Also we can quickly compare with that if you run into trouble.

Thank you for cooperation and for using our Community Forum

I reinstalled the CMSIS Pack and also freshly imported the peripheral_server_sleep example (only change made to the RFCLK_FREQ) and I still have the issue. Like I mentioned earlier, I don’t see this issue with either the peripheral_server_standby or the peripheral_server_sleep with sleep disabled. If you do not see this issue with the same eval board, then I guess it is likely a bad eval board?


It would be useful to try the code on the other RSL10 board. Do you have such possibility?
Next, the USB power source you are running the EVB from (ie. a powered USB hub) or even a regulated PSU through the external power headers, is it stable?

Thank you for cooperation and for using our Community Forum.

The power supplies are stable and I have tried both USB and a PSU (skipping the eval board regulator). I don’t have another RSL10 board right now but will let you know once I get hold of one and do further testing. Thanks

1 Like

Hi @rastislav.stefun ,

I was finally able to test a custom RSL10 board and I can confirm that 48 MHz works without any issues. So something must be wrong with the eval board I have.

BTW is this option you mentioned now available in the latest 3.5.285 release? I couldn’t find anything about it in the release notes.

Hi @svk,

Nice to hear that the root of issue has been identified and resolved.

You can set MD bit by BLE_Set_ForcedMDbit function located in rwip.h. This is new feature of CMSIS Pack version 3.5.285.

Thank you for using our Community Forum.

Hi @rastislav.stefun

Thanks, I was able to clear the MD bit (not “set”) to combine the notification packet with the connection event. Just curious, does this setting affect retransmission of missed packets at the LL level?


In the retransmitted PDU/s the MD field should be replicated. It might affect after retransmission of missed packets at the LL level.

The MD bit of the Header of the Data Channel PDU is used to indicate that the device has more data to send. Options are:

  • MD bit = 1, there are more data
  • MD bit = 0, there is no more data

If we force the MD bit = 0 for each of transmission and unfortunately, there is missing packet left in the LL and need to resend again. So, on the central side, it will treat these for different packets, not ONE packet as we expect.

If the application doesn’t care this, force MD bit = 0 should be no issue.

Thank you for using our Community Forum.