Hi guys,
as I understood, in HERE4 FW 1.15.4 you configured usage of internal clock as PLL source (OSCILLATOR_HZ =0 in hwdef.dat) and activated trimming of that HSI source from uBlox GPIO output toggled at nominal 1000Hz.
My questions / comments are:
- why doing that relatively expensive and potentially buggy handling (in case you do not plan to save on external 24MHz quartz in newly produced modules)?
Any HSI is imprecise and very temperature-dependent. Even with MCU internal t_junction ADC channel used (as I see it is just used for reporting in AP_GPS_UBLOX::report_pps_interrupt_rate - as hal.analogin->mcu_temperature()) it would be imprecise. But your updates of HSICFGR from AP_GPS_UBLOX::pps_interrupt() once per second just rely on uBlox interrupt rate.
And what in case of GNSS jamming or spoofing - are you sure uBlox will provide correct rate?
Further, from source in stm32h7_mcuconf.h I see you are using HSI64 as PLL source (/4*50/2), but in your thoughts “// each step is 0.175%“ you apply to STM32H75x datasheet “Table 55. HSI48 oscillator characteristics” instead of “Table 56. HSI oscillator characteristic” which says that “HSI user trimming step” may introduce up to -5.2% error at some conditions and drift over temperature 2%…. Please review your implementation in case you absolutely need to use HSI PLL source. It potentially affects DroneCAN and serial baud rates errors, etc.
- as I need to build our modified HERE4 FW anyway, could you please confirm that in the future the external 24MHz quartz will remain in later produced HERE4 modules?
And that reverting the following will work and introduce no regression:
define HAL_HSI_TRIM_USING_PPS 0
OSCILLATOR_HZ 24000000 (in hwdef.dat and also hwdef-bl.dat)