STM32F4 register definitions and PLL settings patch

[Tomasz Gregorek]

Hi Chris

- pll_q = ( (long) ( src_clk * pll_n + src_clk * pll_n / 2 ) ) / pll_m /
48; + pll_q = ( (long) ( src_clk * pll_n ) ) / pll_m / 48;

Your fix for the PLL_Q calculation is correct.
It supposed to be rounding from <=X.5 to X and from >X.5 to (X+1) but first
I messed up the equation second this clock should not exceed 48MHz so
rounding up is not necessarily the best idea.


-#define FLASH_ACR_LATENCY( val ) BSP_FLD32( val, 0, 3 ) -#define
FLASH_ACR_LATENCY_MSK BSP_MSK32( 0, 3 )

+#define STM32F4_FLASH_ACR_LATENCY(val) BSP_FLD32(val, 0, 2) // Flash
access latency +#define STM32F4_FLASH_ACR_LATENCY_GET(reg)
BSP_FLD32GET(reg, 0, 2) +#define STM32F4_FLASH_ACR_LATENCY_SET(reg, val)
BSP_FLD32SET(reg, val, 0, 2)

I would argue about the STM32F4_FLASH_ACR_LATENCY where you use 3LSB of ACR
(up to 7 wait states) which is correct for the STM32F405xx/07xx and
STM32F415xx/17xx while for the STM32F42xxx and STM32F43xxx there are 4LSBs
in use (up to 15 wait states).
I am not sure how to deal with it. Do we need to distinguish for which chip
we are compiling?


Thanks and regards
Tomasz


2014-10-18 11:06 GMT+02:00 Chris Nott <chrisn at vl.com.au>:

> Hi,
>
> I sent these header file changes previously, they didn't get picked up.
>
> I re-merged with the head, cleaned up formatting and fixed a bug with
> PLL_Q setting not generating the right auxiliary clock frequency for USB
> peripheral - Tomasz this was your change, could you please review my fix.
>
> Regards,
> Chris.
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20141018/dce0b8dd/attachment-0002.html>