Help us improve the Power & Sensing Selection Guide. Share feedback

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Level 1
Level 1
Welcome! 5 replies posted First question asked

I need high precision ADC sampling rates, but also must be able to enter deep sleep. The M4 is where all of the ADC sampling and other precision timing takes place, so I have it set up to use the AltHF clock with PLL for HF0 when the M4 wakes up and back to IMO with FLL before entering deep sleep. Here's some initial clock settings (HF0 on path 0).


So far I am...

Before M4 Deep Sleep:

Set pathmux 1 to IMO

Set HF0 source to Path 0

After M4 Wake:

Set pathmux 1 to AltHF

Set HF0 source to Path 1

All four of these steps are returning success and the timing when M4 is active appears good.

But, I am getting a lot of variation in the time it takes for the M4 to set the clocks and move on to the next steps.


Am I going about this in the best way? Any thoughts are greatly appreciated.

Thank you in advance.

1 Solution

It looks there is no tradeoff between the bless deep sleep and ble eco running. BLE HAL will not let the BLESS to enter deep sleep mode as this will stop ECO and thus crash the system. I know that you require both, but you have to make a choice.

View solution in original post

7 Replies
500 replies posted 250 solutions authored 250 replies posted

Your handling of AltHF clock before/after entering DeepSleep looks fine. It might be inevitable to take some time to settle the clock changes.

Note that you have changed HF0 to path0 under Deep Sleep. Can this step be ommited? What if you leave HF0 still on path1 during Deep Sleep mode?


Thank you for your response.

If I leave HF0 on path 1 after switching to IMO I lose my 50MHz clock speed. I could reconfigure the PLL in lieu of switching the HF0 path. That's originally what I was trying to do, but I was having trouble getting the PLL to successfully toggle between the two configurations. That's how I ended up with the FLL.





Notice in the screenshots; the clock change happens at the 15 second line on both and it happened exactly on that line every time. At least until I triggered it earlier than the 12.5s line.

I have a 2.5s BLE advertising interval (taller spike) and the clock change must not be able to happen unless some condition related to BLE is met. I thought it was just that the M0 had to be awake, but I now have an interrupt set up on the M0 that just sits in a delay for a second and the M4 triggers it just prior to calling the clock change and it still doesn't complete until the next advertising packet.

Not sure exactly what is going on here.


For the reason why you not put the HF0 still on path1 under deep sleep mode, do you mean the PLL has trouble recovering after wake up from deep sleep?

Another issue, how could you recognize the clock changes take effective, from perspective of power consumption? It looks from the the chart in post#3 that the power consumption jumps up at the 15s line with the BLE adv spike. However, the power consumption remains high during the subsequent several adv intervals. It looks the device had not get into deep sleep mode during the intervals. This phenomenon is reasonable accoridng to your code logic? I blieve the adv inteval is long enough to put cores under deep sleep.



The first function is a quick RMS reading and completes using the M4 on IMO FLL. Notice the current draw is ~4.5mA avg.

Next you can see the clock change begin because I triggered a FFT recording which is a measurement that uses the M4 on AltHF PLL. Notice I triggered it right after an advertising interval (spike) so it takes nearly the full 2.5 seconds for the clock change to complete. Then when the clock change completes I am now drawing ~7.5mA. Both functions use the M4 at the same clock speed, so I would guess this is indicative of using the BLE ECO.

I commented out my clock change function and below is the result.


Notice the FFT function begins right away. Also notice that it draws the same amount of current.

I can also tell by my FFT results. If I do the clock change I get almost no bin bleed on my FFT. This is indicative of a stable sample rate. These are the bins immediately surrounding 5KHz on my FFT when I put a 5KHz vibration input into the product.


AltHF Result- 5KHz Input

X Y Z Frequency

3 9 4 4996

7 20 11 4998

136 343 203 5000

11 29 16 5002

5 15 8 5004

IMO Result- 5KHz Input

X Y Z Frequency

7 19 10 4984

12 31 16 4986

22 56 30 4988

100 250 135 4990

76 192 104 4992

21 54 29 4994

11 29 15 4996

10 26 13 4998

The bottom half of these cells is when I comment out the clock change. The sample rate changes pretty significantly. My main spike is 10Hz lower and there is much more bin bleed (energy in adjacent bins). This is indicative of an unstable clock causing an unstable sample rate. Hence, the reason I need to use the BLE ECO clock when I am recording measurements that require precision sample rates.

I have been searching around for a BLE function that I can put in my M0p ISR that is triggered prior to the clock change. If I could find a function that wakes up the BLE module like the advertising packet does, perhaps it would be a workaround for this issue.

Thanks again.


Sorry, I'm just seeing my typos here. IMO FLL draws ~3mA and AltHF PLL draws ~4.5mA.


It looks there is no tradeoff between the bless deep sleep and ble eco running. BLE HAL will not let the BLESS to enter deep sleep mode as this will stop ECO and thus crash the system. I know that you require both, but you have to make a choice.