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

[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]

I have not yet, actually. I need to figure out if it's faster to preload all the 64K CCM RAM with my 4 16k buffers, or use CCM RAM for the stack and load only 3 buffers, runs some code, then swap out the last one (or do 2 and then swap in 2 more). Since I'm generating 96k worth of ADC buffer, I need to do some juggling around to de-interleave what the 6 ADC channels captured, and since I can't capture into CCM, CCM becomes my swap area, so to speak

But thanks for pointing out a critical step I might have risked missing, really appreciated

[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