Hi RIOT devs!
I’m currently working on the RIOT port for MCUBoot, 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  and here  which I tried without success.
Thanks in advance!
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 &= ~(PORT_PCR_ISF_MASK | PORT_PCR_MUX(0x07));
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.
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
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…
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.
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.