[riot-devel] CPU clock on kinetis boards

Francisco Javier Acosta Padilla francisco.acosta at inria.fr
Tue Jul 18 12:18:48 CEST 2017


Hi Joakim!

Thanks for the update! I’ll test it asap on PR #7181 which will need an update since #7209 was merged.

I’ll keep you updated on the results.

Cheers,

-- 
Francisco Javier Acosta Padilla
Research Engineer at INRIA Saclay
INFINE Team

On 18 July 2017 at 09:47:13, Joakim Nohlgård (joakim.nohlgard at eistec.se) wrote:

Hi again Francisco,  
See https://github.com/RIOT-OS/RIOT/pull/7379 for an updated clocking  
configuration for Kinetis boards. I think it will be more robust  
against non-default starting values because it tries to go to a safe  
mode (using the internal reference clock) before reconfiguring the  
clock setting registers.  

Best regards,  
Joakim  

On Tue, Jun 13, 2017 at 3:12 PM, Francisco Javier Acosta Padilla  
<francisco.acosta at inria.fr> wrote:  
> Hi Joakim! Thanks for the hints.  
>  
> Your proposed approach at a first sight it seemed to work, then I rebased on  
> your PRs and it didn’t work anymore. But more strange, I reverted your  
> commits and it doesn’t work either… However, with the clock configuration  
> that I proposed before it still works, either with your commits or without.  
>  
> I continue my quest…  
>  
> Cheers,  
>  
> --  
> Francisco Javier Acosta Padilla  
> Research Engineer at INRIA Saclay  
> INFINE Team  
>  
> On 12 June 2017 at 19:36:46, Joakim Nohlgård (joakim.nohlgard at eistec.se)  
> wrote:  
>  
> Hi,  
> I think the wisest choice is probably to switch to FEI mode first to use the  
> internal oscillator before booting a new image. That is the same mode that  
> the mcu comes up in after a hardware reset.  
>  
> There are some relevant PRs open on GitHub for the Kinetis clocking:  
> https://github.com/RIOT-OS/RIOT/pull/6986 move k64f clock configuration to  
> board config  
> https://github.com/RIOT-OS/RIOT/pull/6978 MCG improvements  
>  
> Best regards,  
> Joakim  
>  
>  
> On Jun 12, 2017 16:36, "Francisco Javier Acosta Padilla"  
> <francisco.acosta at inria.fr> wrote:  
>  
> Hi again!  
>  
> I just made it work, though is super strange why it works… I did:  
>  
> static void cpu_clock_init(void)  
> {  
> /* setup system prescalers */  
> SIM->CLKDIV1 = (  
> SIM_CLKDIV1_OUTDIV1(0) | /* Core/System clock  
> divider */  
> SIM_CLKDIV1_OUTDIV2(1) | /* Bus clock divider */  
> SIM_CLKDIV1_OUTDIV3(1) | /* FlexBus divider, not  
> used in Mulle */  
> SIM_CLKDIV1_OUTDIV4(3)); /* Flash clock divider  
> */  
>  
> //SIM->CLKDIV1 = (uint32_t)SIM_CLKDIV1_60MHZ;  
>  
> /* RMII RXCLK */  
> SIM->SCGC5 |= SIM_SCGC5_PORTA_MASK;  
> PORTA->PCR[18] &= ~(PORT_PCR_ISF_MASK | PORT_PCR_MUX(0x07));  
>  
> kinetis_mcg_set_mode(KINETIS_MCG_PEE);  
> }  
>  
> And it works… any explanation? I took the values from the k60f code (mulle)  
> which seems to be completely different to the values contained in the macro  
> SIM_CLKDIV1_60MHZ (0, 0, 1, 2 values). Therefore, I have no idea on which  
> speed the clock is running.  
>  
> BTW, with this code also works for a “normal” build, compiling and flashing  
> as usual.  
>  
> I’ll look at the manual to see why we do that on RIOT (it’s not documented)  
> and maybe submit some PRs to both add doc and fix the setup if needed.  
>  
> Cheers,  
>  
> --  
> Francisco Javier Acosta Padilla  
> Research Engineer at INRIA Saclay  
> INFINE Team  
>  
> On 12 June 2017 at 15:16:28, Francisco Javier Acosta Padilla  
> (francisco.acosta at inria.fr) wrote:  
>  
> Hi RIOT devs!  
>  
> I’m currently working on the RIOT port for MCUBoot[1], which takes the  
> frdm-k64f board as a reference board, and that’s also supported by RIOT and  
> other OSs using MCUBoot.  
>  
> My first goal is to provide a “bootable” image compiled in RIOT and booted  
> by MCUBoot built for mynewt.  
>  
> The work is going well so far, but I’m facing a problem which was also  
> present while coding the RIOT bootloader. Namely, the problem is that the  
> bootloader initialises the clock to a specific speed to run the booting  
> algorithm, which goal is to boot an OS in another flash position, an thus  
> the clock is initialised again leading to a clock crash.  
>  
> Does anyone knows a “safe” way to reset the clock config to afterwards  
> configure it to the desired speed? Currently, as the code shows for the  
> k64f, the assumption is that the clock is in it’s default condition, which  
> is true when a reset is triggered, but now in this new context it’s not true  
> anymore.  
>  
> I have seen some examples here [2] and here [3] which I tried without  
> success.  
>  
> Thanks in advance!  
>  
> Cheers,  
>  
> --  
> Francisco Javier Acosta Padilla  
> Research Engineer at INRIA Saclay  
> INFINE Team  
>  
> [1] https://github.com/runtimeco/mcuboot/  
> [2]  
> https://github.com/apache/incubator-mynewt-core/blob/master/hw/mcu/nxp/src/ext/sdk-2.0-frdm-k64f_b160321/devices/MK64F12/drivers/fsl_clock.h#L897  
> [3] https://github.com/RIOT-OS/RIOT/blob/master/boards/mulle/board.c#L170  
>  
>  
> _______________________________________________  
> devel mailing list  
> devel at riot-os.org  
> https://lists.riot-os.org/mailman/listinfo/devel  
>  
>  
> _______________________________________________  
> devel mailing list  
> devel at riot-os.org  
> https://lists.riot-os.org/mailman/listinfo/devel  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20170718/a8421002/attachment.html>


More information about the devel mailing list