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.aco...@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@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Reply via email to