STM32F729 Discovery HSE Clock

[steved]

The changes made to the 32FXX clocks in the past 48 hours caused my program (pretty much the FAT/LWIP demo but with I2C enabled), running on F729 Discovery to hang waiting for the HSERDY bit.

Solved by commenting out the STM32_HSE_BYPASS definition in the board file - which is strange because the board appears to have an external oscillator, rather than a crystal (both in the board manual and visually).

Will investigate further.

[Giovanni]

Thanks, let us know, F7 support is still experimental at this point.

Giovanni

[steved]

Have got round to looking at this, from the perspective of getting the I2C port right.
I think some of the prescaler settings in mcuconf.h need tweaking, so that maximum internal frequency limits aren't exceeded:

Code: Select all

#define STM32_SW                            STM32_SW_PLL
#define STM32_PLLSRC                        STM32_PLLSRC_HSE    /* 25MHz oscillator on board */
#define STM32_PLLM_VALUE                    25                  /* 1MHz into PLL */
#define STM32_PLLN_VALUE                    432                 /* 432MHz out of PLL VCO */
#define STM32_PLLP_VALUE                    2                   /* 216MHz SYSCLK  */
#define STM32_PLLQ_VALUE                    9                   /* 48MHz for USB */
#define STM32_HPRE                          STM32_HPRE_DIV1     /* 216MHz to APB Prescalers */
#define STM32_PPRE1                         STM32_PPRE1_DIV8    /* Changed from 4 to 8 - max 45MHz here */
#define STM32_PPRE2                         STM32_PPRE2_DIV4    /* Changed from 2 to 4 - max 90MHz here */

With these settings, #define STM32_HSE_BYPASS can be uncommented again in the board file.

The alternative is to change the APB presecaler to 2, and leave the other settings unchanged (if I've understood the manual correctly)

Not sure of the effects on other peripherals

[Giovanni]

Hi,

Exactly which limit is exceeded? the checks should not allow that, this is why ask. The limits are taken from the data sheet.

Note that the BYPASS support has been broken for a couple weeks, I reverted the faulty change last week.

Giovanni

[steved]

Note that the BYPASS support has been broken for a couple weeks, I reverted the faulty change last week.
Giovanni

I might have been chasing a problem which has been fixed! Just tried with the original settings, and it works.

I did notice a couple of things about the clocks:
1. The limits are variable depending on the power mode (at least in absolute frequency terms). I see that you determine the power mode from the configured clock frequencies - not sure in my own mind whether that's the right way round; certainly suggest that its highlighted as a design choice (maybe several selectable sets of values in mcuconf.h which reflect different power/speed strategies?)

Trying to match up terminology, I think I'm looking at Chibi's PCLK1 and PCLK2 here, corresponding to ST's APB1 and APB2.
The data sheet limits on these are 45MHz and 90MHz respectively in non-overdrive mode (54MHz and 108MHz in non-overdrive mode - missed this initially)
So a simple check against STM32_PLLOUT_MAX isn't quite right - the test needs to take overdrive mode into account

Having dug into the clock-related code a bit more, must say I'm impressed with the general level of checking in this area - vastly changed from those simple days when you just decided what crystal frequency to use!

[Giovanni]

Yes, the devices are becoming more and more complex. It is the hardest part in a port now.

Giovanni