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.
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.