2020-12-10 07:11 PM
Hello,
We are using the STM32H745 dual-core MCU for a mostly-analog sensor project. The M4 core is running at 240 MHz and generating a signal on the fly that is passed to the DAC via a DMA stream in circular buffer mode. This part works great.
The signal is routed through some external op-amps and other analog circuitry and eventually makes its way back to one of the MCU's OPAMP inputs. We'd like for the M7 core to run at 480 MHz and use the ADC to sample the signal back and then perform some analysis. This part hasn't been implemented yet but we have similar functionality in other projects and this doesn't look to be a problem.
The issue is that we'd like for the ADC sampling to be precisely synchronized to the DAC signal generation. On other MCUs, the ADC can be configured so that it is clocked by either the PLL or by a fraction of the HCLK bus clock ("adc_hclk"). However, on the STM32H745 it appears that the ADC can be clocked by either the PLL or by a fraction of the SYSCLK ("adc_sclk").
In our configuration, SYSCLK would be 480 MHz and HCLK would be 240 MHz. The timers are driven by HCLK. The ADC would be driven by SYSCLK so the timers and the ADC would be "sort of" synchronized. However it seems like there is no guarantee that, say, HCLK=SYSCLK/2=240 MHz and adc_sclk=SYSCLK/2=240 MHz are synchronized with each other since they could be out of phase by one SYSCLK tick.
I believe that the RM0399 v3 alludes to this in the description of "option 2" in section 26.4.3:
"Option 2) has the advantage of using the system without additional PLL. In addition, when adc_sclk is twice faster than the adc_hclk clock, the latency between the trigger and the start of conversion is fixed. This can be useful when the ADC is triggered by a timer and if the application requires that the ADC is precisely triggered without any uncertainty (otherwise, an uncertainty of the trigger instant is added by the resynchronizations between the two clock domains)."
In our case, adc_sclk would be 240 MHz and adc_hclk would also be 240 MHz (since we require the M4 core to run at 240 MHz), so I don't see how we could ever get adc_sclk to be double adc_hclk.
Does this mean we just have to live with a random jitter of a single 480 MHz SYSCLK tick between our DAC trigger and the ADC trigger? I mean, it's not huge but it is a bit distasteful.
I also found the following presentation by Googling "STM32H7 ADC":
In that presentation, on page 9 they describe a completely different clocking scheme where HCLK is used instead of SYSCLK, but as far as I can tell that is in contradiction with RM0399. If that presentation was actually correct and the manual was in error then there wouldn't be a resynchronization issue.
Thanks, and any advice would be appreciated!
2020-12-14 11:38 AM
Anyone from ST or the community have any thoughts on this?
2020-12-30 09:12 PM
To further muddy the waters, I noticed a discrepancy in RM0399 Rev 3 today. In section 26.4.3, as I quoted previously we have:
"In addition, when adc_sclk is twice faster than the adc_hclk clock, the latency between the trigger and the start of conversion is fixed."
However, in section 26.7.2 where ADCx_CCR.CKMODE is documented, we have:
"In synchronous clock mode, when adc_ker_ck = 2 x adc_hclk, there is no jitter in the delay from a timer trigger to the start of a conversion."
But adc_ker_ck is completely different from adc_sclk (and slower since there is at least a prescaler of 2 dividing adc_sclk down to adc_ker_ck according to Figure 142).
We would really appreciate if someone from ST could shed some light on this, it seems to be a documentation bug of some sort.