STM32F4 register definitions and PLL settings patch

[Tomasz Gregorek]

Hi Chris

2014-10-19 8:36 GMT+02:00 Chris Nott <chrisn at vl.com.au>:

>  Hi,
>
> On 18/10/2014 3:45 AM, Tomasz Gregorek wrote:
>
> 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.
>
> A check for clock <= 48MHz would be good. Even better if we can check if
> USB is used and warn if it is not exactly 48MHz..
>
>
>
>  -#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?
>
> I think it should be safe to use 3 bits as it was. It's a pretty low risk
> that someone will accidentally set a flash latency > 7 and it is pretty
> likely a write to that bit would be ignored in the hardware anyway.
>
> Ideally yes when we support STM42xxx etc. as well we should add a build
> option, but there may be more we need to add, like the operating chip
> voltage. Honesty my priority so far is first adding register maps and
> example projects to make RTEMS more useful out of the box for standard
> boards like STM32F4Discovery.
>


I vote to keep simplified pll_q calculation, maybe add more comment in the
configuration header for it. If we add a check, than also a switch to turn
on/off USB would be needed so the warning will not print out if USB is not
used. Of course it will be very good to have these but I agree with your
priority of making RTEMS more useful on Discovery like boards first and we
can keep upgrading the bsp with time.

Yes, there are more registers specific to specific CPU versions, different
number of UARTs and other peripherals. As above, lets keep it simple for
the start.

Myself I have working UART driver with interrupt driven data receiver
(currently it is polled UART). I should be able to push it in few days. I2C
is half working but will take more time due to work overload.

Cheers
Tomasz


>
>
>
>  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
>>
>
>
>
> _______________________________________________
> 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/20141019/ea64ebb2/attachment-0002.html>