STM32F4: changing clock speed dynamically (runtime). What do I need to look out for?

[fbar]

I'm writing an application for a STM32F407 that requires very high speed ADC for 6 channels (two for each ADC, using regular simultaneous scanned mode), then once a series of conditions are met, perform quite a few cross correlation calculations for very long sequences, requiring the fastest performance possible. I'm using the SPL libraries, incidentally, not the HAL/CubeMX

Due to how the clocks work on a F407, the fastest ADC conversion cycle happens with a 144MHz clock. But the max clock is 168MHz, and that's ~16% faster when performing DSP operations. I do understand how to set the clock for both 144MHz and 168MHz, with all the right PLL_M, N, P and Q values

I was thinking of setting the board up at boot with 144MHz. sample with the fastest ADC clock and, once my conditions are met, switch the clock to 168MHz before performing the cross correlations. Whatever time it takes to dynamically change the clock, I'll more than make it up while running the long (>2 seconds) calculations 16% faster

This article seems to indicate a way to do it http://embeddedsystemengineering.blogspot.com/2015/06/stm32f4-discovery-tutorial-4-configure.html

What would happen if I boot the system with 144MHz clock, switch to 168MHz, then back to 144MHz for another cycle and so on? It seems to work, but I'm not sure if I'm missing any downside not showing up in a short test (or reliability issues over time). I also plan to use USB, so I understand the need to always have a 48MHz clock for that

[turboscrew]

Correcte if I'm wrong, but I think you need a backup clock source. You first need to switch to the backup clock and disable PLL before you can change the values. It takes some time for the PLL to stop and start. I think the operation takes something like 1 - 2 milliseconds. Starting and stopping the backup clock takes some milliseconds more, if you don't let it run on the side.

[fbar]

Thanks for the reply. Can you please help me understand what you mean by "backup clock source"? Please note that when changing clock, I would be ok with having nothing else running (no timer, dma transfer, etc), and just looping until the PLL is stable (i.e. while (!RCC_WaitForHSEStartUp()); RCC_PLLConfig(new values);)

Would I still need a backup clock (I assume HSI?) in that case?

[waclawek.jan]

Your mcu can't run from PLL while you change it (it probably won't allow to change it while running out of it).

So you need to switch temporarily to a different source in RCC_CFGR.SW - HSE is OK if you are running it because of the PLL anyway - switch off PLL, change its settings, switch it back on, wait until it locks, meantime change the FLASH latency accordingly, and then switch back to PLL as the primary source in RCC_CFGR.SW.

JW

[S.Ma]

Agreed. Choice of clock tree is important. Peripherals should remain with constant frequency while core is dynamically prescaled. STM32L4 with MSI and clock selector for most peripherals follow this vision.

[waclawek.jan]

> I'm not sure if I'm missing any downside

I don't think there's any (except of those you already mentioned, explicitly stemming from the rigid clocking scheme in 'F4xx).

Going for 16% sounds desperate. Do you achieve the full 16% performance increase, given different FLASH latency? Do you have performed all the "usual" measures, including having stack and the most critical (most often used) variables in CCRAM, and any algorithmic improvements available? Have you considered moving to a different 'F4 (namely 'F427) with slightly even higher maximum clock frequency and with (only slightly, unfortunately) better clock tree? Have you considered moving to a 'F7?

JW

[fbar]

Desperate is one way to put it :) And, no, haven't done full performance analysis yet, just a quick set of tests, and 168MHz is definitely faster.

As far as I can tell, the flash wait states are 5 for both 144MHz and 168MHz, so there should be a linear improvement there (the F4 manual says that at <150MHz could be only 4, but the system_stm32f4xx file for the STM32F4 Discovery board at 144MHz uses 5). And the ST ART should further reduce effective wait states, especially for a short, tightly coupled loop of CM4 DSP instructions like the ones that make the bulk of my execution time. I want to also try moving that part of the code to SRAM, to see if there's any real difference, but given how effective ART seems to be, a small loop might be faster in FLASH than SRAM

And, yes, I do use CCM RAM already: I convert my signal using ADC with DMA transfer, preprocess the various signals and move the data into CCM RAM, then process the signals with the highly optimized DSP library cross correlation (which does an amazing job of parallelizing with the M4 DSP instructions, especially when using Q15 number format)

And, yes, changing board is an option. But for hobbyist projects, the STM32F407VG boards at around $12 are hard to beat. There are no discovery/nucleo boards with the F417/427, nor much from the Chinese suppliers, so the additional cost would be out of line for the performance gain. The Nucleo F7 is very tempting at twice the performance, and not that expensive (and has the 3 high speed ADCs I need, not to mention extra SRAM). But no SPL, only the newer LL libraries (I really, really dislike the HAL). But for now I would like to maximize the board I have. If nothing else, it's a good learning experience.

Thanks for the additional thoughts, really appreciate the opportunity to brainstorm about this

[S.Ma]

Well, it seems you are ready to go to deep optimization of the code, looking at the assembly generated by the compiler. Also if using floats, try Q31 (fractional bits) or instead of moving data, move by computing, interpolate vs math functions, precompute and use lookup tables, put the interrupt vectors and ISR in RAM to prevent Flash ART/core pipeline jumping too much. It's going to be fun. What's difficult to know is which optimisation gives the best return to save development time.

[fbar]

Thanks for the additional input. I am actually using Q15 which works incredibly well for 12 bit ADC signals, and arm_correlate_*** functions from the CMSIS library (and the -Os compiler flag, which has a rather dramatic effect). Given how optimized those are for a specific format of input array (to use SIMD and SMLALD CM4 DSP instructions), I need to move data from the ADC buffer to a "signal buffer". Since I'm using all 3 ADCs, with 2 channels each and DMA transfer, the resulting ADC buffer is an interleaved CH1_1, CH2_1, CH3_1, CH4_1, CH5_1, CH6_1, then CH1_2, CH2_2, etc. I had my own highly optimized cross correlation algorithm for a F103 which worked well with an interleaved buffer, but it's no match for using DSP instructions on 4 values at a time... unsurprisingly, the M4 DSP core makes an amazing difference when doing cross correlation, and the CMSIS DSP libraries are really already highly optimized (I still managed to shave ~30% from the execution time by limiting the usual cross correlation window, thanks to how my signals are captured and stored in order). 95% of my loop time is a series of cross correlations on multiple signals, so the highest return is to focus on making the cross correlation itself as fast as possible. Pretty much anything else around it (like copying the ADC buffer into signal arrays) has no real effect on the final outcome. And I'm satisfied that the core cross correlation function I'm using (a modified version of the CMSIS code) is as fast as it could be, and fully contained in ART

Would not have thought about the ISR in RAM, but that makes a ton of sense and I will remember for the future. In my case, I actually disable all interrupts while running the DSP analysis, so there isn't much to gain there

Still, no matter what I do, any optimization that works at 144MHz, also works ~16% faster at 168MHz, so switching the clock is another helpful trick. Clearly an F7 would make even more difference (and I could use the extra RAM to avoid a couple of extra buffer copies to juggle the 128k+64k F407 RAM)

[S.Ma]

I hope that you placed the stack in the CCM memory...

[S.Ma]

Don't know if useful in your ADC data processing, some new STM32 have DFSDM feed from ADC streams.

[fbar]

Interesting suggestion... but from what I can tell, delta sigma converters have pretty low data rates, usually good for audio frequency analysis. I'm trying to convert 6 ADC signals at roughly 1Msps, and the F4 triple mode gives me a max 1.2Msps (it's 2.4Msps, but since I convert 2 channels per ADC, I can get only half the max rate

Do you know of a way to convert a an analog signal with delta sigma at ~1Msps?

[S.Ma]

Well, for demanding analog front end and datarates, maybe this one or its SPI version:

https://www.analog.com/en/products/ad7760.html

Check how parallel memory interface FMC can be connected to it.

In SPI 16 bit mode, this would correspond to 16 MHz min per daisy chained ADC channel.

[fbar]

Yes, that would work, thanks for helping me learn something new. Definitely an interesting option

At this point, though. the added complexity would make it less appealing for my specific case than using a Nucleo-H7 board, which would not only increase the ADC sampling rate (from 1.2Msps for all 6 channels at 12 bits to 2.25Msps for all 6 channels at 12 bits for 6 channels or 1.8Msps for all 6 channels at the much increased 16 bits sampling), but also provide roughly 4 times faster DSP performance for the cross correlation (I'm looking at this one here, did not realize how much better an H7 would be https://community.st.com/s/question/0D50X0000AaZjwySQC/stm32f7-can-i-use-adc-conversions-at-highest-speed-24msps-with-216mhz-clock)

[turboscrew]

What I meant was that the clock switching takes a couple of milliseconds that the processor polls the readiness of clocks. Also, typically RC oscillator is not accurate enough for USB, although some devices have a special, more accurate RC oscillatot (was it 48 MHz?) that is accurate enough for USB. If you don't have that, also USB stops for the changing of clock frequency.

[fbar]

Got it, yes. As a matter of fact, potential USB instability is the main issue I'm facing when rapidly switching clock speeds